laoyang 9f41e1622e v45-① 同步基础字段:53 张业务表补 updated_at + deleted_at(结构 v33)
用户 2026-10-12 定「本地优先(local-first)」架构,客户端要落盘 + 增量同步。
本批只做**服务端地基**(不含客户端代码)。

## 为什么必须补这两个字段
增量同步要先能回答两个问题,而实测现状两个都答不了:
· **哪些行变了?** —— 50 张表里只有 21 张有 `updated_at`
  (`anniversaries` / `ledger_entries` / `task_boards` 等都没有);
· **哪些行被删了?** —— **一张有 `deleted_at` 的都没有**。
  硬删除在客户端**永远不可见**(没有墓碑,无法区分"服务端删了"与"本地没拉到")
  ⇒ 会一直显示幽灵数据。

## 做法
· 53 张业务表补 `updated_at`:
  `DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP`
  —— **由 MySQL 自己维护**,任何真实 UPDATE 都自动刷新。
  ⇒ **业务代码一行都不用改**,也就不存在"某处忘了更新 updated_at"的漏网之鱼
     (手工 `SET updated_at = NOW()` 那种做法迟早会漏)。
· 53 张业务表补 `deleted_at`(软删除墓碑,NULL = 未删)。
  ⚠️ 本批**只加列、不改删除逻辑** —— 改成软删除是后续独立一步,
     先加列的好处是那步开始时不必再动表结构。
· 按有无 `family_id` 加 `idx_<表>_sync` 索引,供 `WHERE family_id=? AND updated_at>?` 用。
· ⛔ 8 张**故意不加**(凭据/字典/本地偏好):`api_tokens` `dav_credentials`
  `settings` `user_settings` `regions` `nav_engines` `nav_settings` `weread_snapshots`
  —— 同步白名单应当显式而简短。

## 过程中发现并修正的一个清单缺陷(重要)
第一版清单**只扫了 `statements()`**,漏掉 11 张"建在 `ensure()` 迁移段里"的表
(`anniversaries` / `ledgers` / `ledger_entries` / `ledger_shares` /
`ledger_entry_snapshots` / `task_boards` / `task_categories` /
`calendar_event_skips` / `anniversary_people` / `person_jobs` / `person_notes`)。
**线上实测才发现 `anniversaries` 没有 updated_at。**
⇒ 教训:找"全部表"必须扫**整个文件**(本文件建表语句分散在两个函数里),
   只扫建表函数必然漏。

## 验证(线上实测)
· `deleted_at` 53 列 / `idx_*_sync` 53 张 —— 与清单精确一致 ✓
· **`ON UPDATE` 真的生效**:改 `cinemas.name` 后
  `updated_at` 16:19:19 → 16:27:28 自动刷新 ✓(业务代码未插手)
  ⚠️ 首次测试误报"没生效":当时用 `SET name = name`(**值没变**),
     MySQL 本来就不触发 ON UPDATE —— 是测试方法错,不是缺陷。
· 回归:首页/people/calendar/api 均 302/401(未登录的正常响应),无 500 ✓
· 诊断页用完即删、404 复验通过 ✓
2026-10-12 16:28:29 +08:00
2026-09-29 15:08:42 +00:00

FamilyBook

家书,记录家庭的全部生活,一本用岁月写成的家谱。

把一个家的「人」「日子」「去过的地方、看过的电影」收进同一本书里。


它是什么

一个自托管的家庭生活系统。它不是又一个待办清单,而是这个家的长期档案 —— 十年之后还能翻出孩子第一次观影的票根、那年暑假走过的路线。

围绕三个圈展开:

  • 人:家庭成员、亲友通讯录,以及他们之间的共享关系
  • 时间:日历、日程、提醒,以及任务的期限
  • 事件:观影、旅行、其他活动 —— 一切都落在同一条时间轴上

它在做什么

阶段 主题 内容
0 地基 名册、账号、登录、权限模型、安装向导
1 通信 通讯录、共享给某个成员、CardDAV 服务端
2 时间 日历本、重复日程、提醒、CalDAV 服务端
3 归一 观影与旅行迁入统一事件模型
4 任务 任务管理,期限自动映射成日历事件
5 回看 统计、年度家书、时间轴

当前进度:阶段 0 起步,仓库里只有图标与脚手架。

技术选型

  • PHP 7.4+(无框架、无 Composer,上传到站点目录即可运行)
  • MySQL 5.7+ / 8.0(utf8mb4)
  • 前端为原生 HTML / CSS / JavaScript,无构建步骤

⚠️ 注意 CalDAV / CardDAV 是双向协议,和单纯的 .ics 文件导出不是一个量级的东西。

部署

  1. 把代码放到站点根目录;
  2. 复制 config.example.php 为 config.php,填写数据库与 app_key;
  3. 访问站点根,按引导页确认 PHP 版本、扩展、配置、数据库连接四项都通过。

config.php 不入库(已在 .gitignore 中忽略),其中包含数据库口令与加密密钥。

⚠️ app_key 一旦开始记录数据就不能再改(换掉即解不开已有数据), 并且它必须单独备份 —— 密钥丢失等同于数据永久丢失。

隐私

身份证号、手机号属于敏感个人信息,一律加密存储。 (就家庭自用而言,身份证号其实没有多少必须存的场景,启用前请三思。)

图标

见 assets/icons/。概念是「这本书就是家」:屋顶即一本摊开的书, 屋顶下纸做的墙上,三行横线是这个家写下的日子。

开源协议

Apache License 2.0

S
Description
家书,记录家庭的全部生活,一个家庭用岁月写成的书。
Readme Apache-2.0
8.5 MiB
Languages
PHP 81.6%
JavaScript 9.3%
CSS 9.1%