Files
FamilyBook/app
laoyang 3d745b65b2 领证纪念日实际关联 2 人;端上只读了老列所以只带出 1 个 (#91d)
用户 2026-11-05:「你去查一下这个领证纪念日到底关联了几个人,数据库里。」

查库结果:
  anniversaries #2 「领证纪念日」
    person_id = 1                    ← **老列**,只能存一个
  anniversary_people(多对多表)
    person_id=1  杨永全
    person_id=3  洪博为
    = **2 人**                        ← 真正的事实

根因链(两处都缺一不可):

① 服务端 `occurrences()` 从来没输出 `person_ids`
   `peopleMap()`(查多对多表)只在 `split()` 里用了 —— 那是**网页端**的路径;
   `occurrences()` 是 API(鸿蒙端)用的,只透传了 `person_id` 这个老列。
   ⇒ 端上永远只拿到 1 个人。
   ⇒ occurrences 开头一次性 `peopleMap(array_column($all,'id'))`,
     输出 `person_ids`(多对多表为准,为空才退回老列)。

② 端上编辑框只读 `dayDetail.personId`(单个数字)
   ⇒ 改用 `personIds.slice()`(完整列表)。
   FbRecentDay 新增 `personIds: number[]`;`parseRecentDays` 里
   "person_ids 非空就用它,否则退回 person_id"。

⚠️ 老列 `anniversaries.person_id` 是升级到多对多之前的遗留字段。
   两边不一致时**以多对多表为准**(用户在新版界面上改的就是那张表)。
⚠️ 部署时踩了一次:第一次 scp 没生效(服务端文件 grep 不到新代码),
   导致验证结果仍是空的。重新部署并 md5 比对后才确认生效。

实测(部署后):
  领证纪念日   person_ids = [1,3]  → 杨永全、洪博为 ✅
  杨永全 的生日 person_ids = [1]    (派生条目单个人)
  其余派生条目同理,各 1 人。

编译通过,已装真机。
2026-11-05 20:57:24 +08:00
..