HistoryPhoto-linStudio 一開始其實跑得起來。
照片能掃、日期能找、地圖也能顯示。直到照片數量一多，我才發現一個問題：
能用，跟用得舒服，是兩件完全不同的事。
問題不是錯誤，而是「慢」
一開始的作法很直覺：
每次搜尋，就重新掃描資料夾、讀取照片資訊、判斷日期與 GPS。
在照片不多的時候，這樣完全沒問題。
但當資料夾裡開始累積到幾萬張照片，體驗就開始變了。
不是當掉，而是：
- 搜尋要等
- 地圖要等
- 使用者不知道現在在等什麼
這種「沒有壞，但不順」的狀態，最難處理。
我意識到：照片不該每次都重新讀
後來我回頭想了一件事：
照片的拍攝日期、GPS、檔案路徑，
其實都不是會頻繁改變的資料。
既然如此，就不該在每一次操作時，
都重新把它們從檔案系統裡撈一遍。
這時候，索引就成了一個很自然的選擇。
為什麼選 SQLite，而不是其他方案
我沒有考慮太複雜的架構，原因很單純：
- 需要 本機可用
- 不想增加部署負擔
- 不想引入額外服務或常駐程序
SQLite 剛好符合這些條件。
它只是檔案，但又具備資料庫該有的查詢能力。
對一個單機工具來說，剛剛好。
索引加入後，改變的不只是速度
加上 SQLite 之後，最明顯的當然是效能。
- 照片掃描只做一次
- 日期搜尋幾乎是即時
- 地圖可以邊掃描邊顯示
但真正的差異，其實在「心理層面」。
使用者不用再猜：
現在到底是在等，還是卡住了？
畫面會持續更新，資料會逐步出現，
這讓整個操作變得安心很多。
我為此重新調整了整個流程
引入索引之後，很多原本的設計也必須一起調整：
- 掃描與顯示不再綁在同一個節奏
- 地圖可以即時更新，不必等全部完成
- 資料是否存在，變成「查詢」而不是「判斷」
這其實是一個架構層級的轉換，而不只是效能優化。
這是我很在意的一個轉折點
如果只看功能列表，SQLite 只是其中一行。
但對我來說，它代表的是：
這個工具開始被當成「會長期使用的東西」來設計。
不是為了跑一次，而是為了反覆回頭看。
接下來還會改什麼
在索引穩定之後，才有餘裕去想其他事情：
- 地圖顯示方式
- 群聚的取捨
- 多語系支援
- 操作流程的細節
這些改動，之後也會慢慢整理成文章。
補充說明
HistoryPhoto-linStudio 是一個只在本機運作的照片回顧工具，
所有索引與處理都在使用者電腦上完成，不上傳照片。
目前已上架 Microsoft Store：
🔗 https://apps.microsoft.com/detail/9NL8S4587L5W
