Modify backend database structure:

1. photos table: remove album_id field, add filename field, add photo_time field
   1. filename defaults to the file name when the photo is uploaded, allowing users to modify the file name after uploading
   2. photo_time extraction: extract the shooting time of the photo from the photo's metadata and store it in the photo_time field. If there is no shooting time in the metadata, the time when the photo was uploaded is used by default.
2. Add album_photos table to store the many-to-many relationship between photos and albums. One photo may correspond to multiple albums, and one album contains multiple photos.
3. album_photos table structure:
   • id: primary key
   • album_id: album ID, foreign key referencing albums table
   • photo_id: photo ID, foreign key referencing photos table
   • created_at: creation time
4. photo_metadata table: modify camera_info to exif_info field, used to store the camera information of the photo. Location information includes two types: one is latitude and longitude, and the other is human-readable address information (such as city, street, etc., which needs to be obtained from third-party APIs, temporarily reserving the interface for future extension), and returning the address information to the frontend for display.
5. Modify the corresponding CRUD code and API interfaces for both frontend and backend to correspond completely.

Specific implementation plan for modifying backend database structure:

1. photos table structure adjustment:

   • Remove album_id field
   • Add filename field: VARCHAR(255), storing photo file name
   • Add photo_time field: TIMESTAMP, storing photo shooting time
   • Implementation logic:
     • Filename processing: automatically fill in the original file name when uploading, providing API interface for users to modify
     • Photo time processing: prioritize extracting DateTimeOriginal field from EXIF metadata. If not available, extract time from file name (formats such as 20230815_123456, 20230815, etc.). If the file name also has no time information, use the current system time.

2. Add album_photos association table:

   • Table structure:
     • id: INT PRIMARY KEY AUTO_INCREMENT
     • album_id: INT NOT NULL, foreign key constraint REFERENCES albums(id)
     • photo_id: INT NOT NULL, foreign key constraint REFERENCES photos(id)
     • created_at: TIMESTAMP DEFAULT CURRENT_TIMESTAMP
   • Create composite unique index (album_id, photo_id) to prevent duplicate associations

3. photo_metadata table modification:

   • Rename camera_info to exif_info: TEXT, storing complete EXIF metadata
   • Add location field: JSON, storing structured location information
     • Includes: latitude (float), longitude (float), formatted_address (string)
   • Keep location_api field: VARCHAR(255), reserved for subsequent address parsing API

4. API interface adjustment:

   • Photo related interfaces:
     • Upload interface: return complete photo information including filename
     • Update interface: support modifying filename
     • Query interface: return list of all album IDs associated with the photo
   • Album related interfaces:
     • Add/Remove photos: operate on album_photos table
     • Query album photos: joint query of photos and album_photos tables

5. Frontend and backend coordination:

   • Update API documentation and TypeScript type definitions
   • Frontend needs adaptation:
     • Photo upload process adjustment
     • Album management interface supports many-to-many relationships
     • Photo detail page displays EXIF information and location data

Refactor photo display functions in PhotosPage.vue and AlbumDetail.vue into a common component module, implementing the following specific optimization plans:

1. Component extraction requirements:

   • Create a common component named PhotoGallery.vue
   • Extract the photo display layout, style, and interaction logic shared by the two pages
   • Retain the special business logic differences of each page

2. Performance optimization plan

   • Implement Virtual Scrolling technology
   • Add Image Lazy Loading function
   • Adopt Responsive Images scheme
   • Implement Image Preloading strategy
   • Add loading state Placeholder

3. Interface design

   • Define unified props interface:
   • photos: Array<Photo> (required)
   • loading: Boolean
   • layoutType: 'grid' | 'masonry' (default 'grid')
   • Other customized parameters

4. Implementation steps

   1. Analyze the functional differences between the two pages
   2. Abstract common logic to PhotoGallery component
   3. Replace original implementation in both pages
   4. Add performance optimization functions
   5. Write unit tests

5. Quality requirements

   • Maintain 100% compatibility with original functions
   • Improve first screen loading performance by more than 30%
   • Scroll smoothness reaches 60FPS
   • Reduce memory usage by 20%
   • Support accessibility

Refactor PhotosPage.vue and PhotoGallery.vue components to achieve the following functional improvements

1. Add "Save to Local" option in batch selection function

   • Add a save button or menu item, clicking it can batch download selected images to the user's device
   • Implement file download function, ensuring support for simultaneous multi-file download
   • Add download progress prompt and completion notification

2. Migrate batch selection function to common component PhotoGallery.vue:

   • Extract batch selection related code from PhotosPage.vue
   • Implement general batch selection logic in PhotoGallery.vue
   • Receive configuration parameters through props and trigger parent component operations through events
   • Ensure style and interaction behavior are consistent with original functions