FinDataHub 能耗过高原因分析与优化方案

改动点：保留 ollama 开机自启（主进程仅约 50MB，可忽略），但设置 OLLAMA_KEEP_ALIVE=60（秒）：35B 模型在 60 秒无请求后自动从内存卸载，AI 评分/摘要调用时再加载。当前 AppConstants.swift:363-365 默认模型 qwen3.6:35b，模型常驻内存是单项最大能耗源，卸载后该项功耗趋近于 0，自启能力与 AI 功能完全保留。

实现代价：极低 —— Ollama 环境变量配置，不动业务代码。

改动点：① 金十 fetch_interval=10s（jin10.py:20）提到 30s；② 默认 --interval 120 提升到 300s；③ 增加「非交易时段（15:05~次日 9:15）与深夜自动降频/暂停抓取」策略 —— 采集器进程保持自启常驻，但空闲时段内部进入低功耗等待，不发起任何网络请求。

实现代价：低 —— 采集器侧加一个时间段判断即可。

改动点：当前 fetchCollectorStatus / fetchBackendStatus 每次启动 Python 解释器。改为：读 PID 文件后 kill -0 <pid> 判断存活（Process 直接调系统调用，不起 Python），并把 collector status 与 backend status 合并为一次查询；轮询间隔 30s → 60s。

实现代价：低~中 —— 复用已有的 /tmp/findatahub-*.pid 文件即可。

改动点：用 IOPSCopyPowerSourcesInfo 检测供电状态，实时切换两档阈值：电池供电时（移动办公场景）自动放大采集间隔（120s→480s）、健康检查 30s→120s、暂停通知轮询与视图自动刷新；插电时恢复全速。自启与全部功能保留，仅移动时自动降功耗 —— 正好命中「出门电池掉得快」的核心场景。

实现代价：低 —— Swift 侧一个电源状态监听 + 一组阈值切换（约 40 行）。

改动点：给所有 Timer.scheduledTimer / DispatchSourceTimer 设置 leeway（如 5s），并统一收敛到同一调度队列，允许 macOS Timer Coalescing 合并唤醒 —— 这是「常驻保留但能休眠」的关键：App 进程仍在，但密集定时器不再阻止系统挂起它。

改动点：三个 1s 的 Timer.publish 仅用于显示「已耗时」，可用 Text(timerInterval:) 或 TimelineView 替代，只在视图可见时刷新，后台自动停止。

改动点：用 launchd 的 StartCalendarInterval 在交易时段（如 9:00~15:30 每 5 分钟）跑一次性采集，替代 7×24 常驻循环。launchd 同样支持开机自启（RunAtLoad），自启体验不变，但彻底消除空闲时段的常驻进程。

改动点：MySQL 仅在数据同步/入库时启动、完成后停止（不影响自启与日常体验）。不移除 disableAutomaticTermination（FinDataHubApp.swift:27-28），而是通过「Timer 全量加 leeway + 空闲暂停轮询」让 macOS 的 App Nap 能挂起常驻 App —— 进程在，但功耗趋近于 0。