v47：地址联想三处接入 / 读书页慢的真根因（会话锁）/ 笔记两处 / 日程状态下线

用户 2026-10-13 七条。拍板：影院只记地址、不存经纬度（后续用高德反查）；
日程状态只删界面与展示、数据库列保留（「后续会有一个整体清理的工作」）。

①🔴 读书页慢 —— 真根因是**会话锁**，不是封面（我先判断错了方向）
  用户原话：「读书现在还是非常慢，就是进入读书这个页面，刚开始还是非常的慢。」
  线上实测（真公网、同一会话连打 3 次）：
      第 1 次 TTFB 0.08s  ← 触发微信读书同步
      第 2 次 TTFB **8.73s**  ← 用户说的"刚开始非常慢"
      第 3 次 TTFB 0.07s
  插桩拿到的服务端时间线把因果钉死：
      21:18:05.483 QUEUED        ← 第 1 个请求排队
      21:18:05.501 FINISH  2ms   ← 响应确实提前发出去了（这步是好的）
      21:18:14.674 SYNC    9.2s  ← 但它仍占着这个人的会话文件锁跑完 9.2 秒
      21:18:14.682 QUEUED        ← 第 2 个请求此刻才真正开始执行
  ⇒ **`fastcgi_finish_request()` 只断开客户端连接、不释放 PHP 文件会话锁。**
    后台同步要 9.2 秒（真打微信读书接口），同一个人的下一个请求一路等到它跑完。
  修法（缺一不可）：
    · `WeRead::queueBackgroundSync()` 回调里 **先 `session_write_close()`、
      再 `fastcgi_finish_request()`**（顺序不能反）；
    · `index.php` 两处"渲染前排同步"的入口排完**立刻放锁**
      （shutdown 回调不一定执行：客户端中断/服务器超时才不放过）；
    · 顺带修 **`Holiday::queueBackgroundFetch()` 的同型问题**（联网 12 秒）。
  为什么以前没发现：v29 引入"后台化"时只验证了"响应是不是提前发出去"，
  **单次请求测量永远看不到这个 bug** —— 必须同一会话连打两次才现形。
  线上复验：修复后连打 4 次 = 0.15 / 0.15 / 0.09 / 0.15 秒（修复前第 2 次 8.73s）；
  后台同步仍正常（`weread_sync_at` 已更新）。

② 封面：顺手也修了（但这不是用户说的那个问题）
  · `media.php` 读 OSS 前先放会话锁（原来从不放，35 张封面串行）；
  · 新增 `Storage::cacheLocally()` 磁盘二级缓存（原来 `read()` 只读不写回）；
  · 让 304 不再先拉整张图（原来先取回 body、再判 `If-None-Match`）。
  线上实测：冷取 149ms（走 OSS）→ 热取 35ms（本地缓存、字节一致）
  → 带 `If-None-Match` 返回 **304 / 19.8ms / 空体**；35 张封面 103ms → 20ms（5 倍）。

③ 地址联想：抽成全站共用一份（`assets/js/addr_suggest.js`）+ 接入三处
  · 影院管理页、观影新增页的「新建影院」弹框、日程地点、行程出发/到达；
  · `layout.php` 按需加载（`[data-addr]` 出现才拉 SDK + 我们的脚本），
    并暴露 `fbLoadAddr(scope)` 给 AJAX 片段（v42 踩过"内联 script 不执行"）；
  · 安全密钥在 SDK 之前设置；回填支持 `data-addr-fill` / `data-addr-for`、
    **只补空白字段**（不覆盖用户手写）、直辖市 `province==city` 去重；
  · 字段名有两套（影院 `address`/`place`，行程 `from_addr`/`to_addr` 缩写 `_addr`），
    `fieldFor()` 带同义词表 + 后缀匹配；
  · 影院**只存地址、不存经纬度**（按用户要求）。

④ 笔记两条
  · 「点保存没反应」真因：附件区是个 `<form>` **套在保存表单里** ——
    HTML 不允许 form 套 form，浏览器丢掉内层标签、保留它的 `</form>`，
    于是**保存按钮成了孤儿**（`button.form === null`），点了不提交也不报错。
    真浏览器实测：修前 `btnInsideForm:false` / 点后 POST=0；修后 true / POST=1。
    改法：附件区改 `<div id="noteAttForm">`，上传按钮用 `formaction`。
  · 详情页宽度：`.note-read { max-width: 820px }` → `none`
    （内容卡 820px vs 下方共享卡 1032px；修后两者都是 1032px）。

⑤ 日程状态下线
  · 删表单里的「状态」下拉、`Calendar::statusWord()`、浮层 JSON 的 `status_word`；
  · **保留** `events.status` 列与 `Calendar::statusOf()`（契约不动，等整体清理）。

验证（新增 5 个套件）：
  · `_fb_v47_addr.py`（接线 24 条）/ `_fb_v47_addr_sim.py`（真浏览器 + 假高德，16 条）
  · `_fb_v47_readperf.py`（缓存与会话锁，23 条）
  · `_fb_v47_notes.py`（真浏览器，9 条）
  · `_b47_readperf_falsify.py`（反向验证 9 个注入）—— **9/9 全抓住**
  · 全量 e2e **1510/0**；vCard 规格+往返 40/0；TB 探针 44/0；
    v44 反向验证 17/0；全流水线 **PUSH_RC=0**（含"第47批形态"静态断言）
  · **线上终验**：读书页整页 81ms、封面 103→20ms、media 冷 149→热 35→304 19.8ms、
    修复前第 2 次请求 8.73s → 修复后 0.15s、地址联想 meta[fb-addr] 带真高德 key

顺带修掉三处**探针自身**的假红/假绿（详见 pitfalls.md）：
  · `_b44_falsify.py` 的"整小时"注入在**整点**与正确实现等价 ⇒ 换成恒错值；
  · `_fb_b44_ui.py` 3b 的并发计时断言在单进程 `php -S` 下必然假红 ⇒ 改断言确定事实；
  · 多处探针的"清理删除"撞沙箱删除门禁 ⇒ 探针**中途死掉**看起来像产品坏了
    ⇒ 统一改成 `_safe_rm()` / 不删。

app/WeRead.php

@@ -691,6 +691,33 @@ final class WeRead
      * ⚠️ 用 `register_shutdown_function` 而不是在这里直接调：
      *    必须等**页面已经渲染完**（输出都发出去）才切断，否则会把页面截断。
      * ⚠️ 同一个请求里只排一次（`$bgQueued`）：读书页会连着调好几次取数。
+     *
+     * 🔴🔴 v47（用户 2026-10-13：「读书现在还是非常慢，进入这个页面刚开始非常慢」）
+     *    —— **必须把会话锁也放掉，否则"后台化"是假的。**
+     *
+     *    现场实测（线上，真公网，同一会话连打 3 次）：
+     *      · 第 1 次  TTFB 0.08s   ← 触发同步
+     *      · 第 2 次  TTFB **8.73s** ← 就是用户说的"刚开始非常慢"
+     *      · 第 3 次  TTFB 0.07s
+     *    服务端时间线（插桩取得）把因果钉死了：
+     *      21:18:05.48 QUEUED          ← 第 1 个请求排队
+     *      21:18:05.50 FINISH  2ms     ← 响应确实提前发出去了（这步是好的）
+     *      21:18:14.67 SYNC    9.2s    ← 但它仍**占着这个人的会话文件锁**跑完 9.2 秒
+     *      21:18:14.68 QUEUED          ← 第 2 个请求此刻才真正开始执行
+     *    ⇒ PHP 的文件会话是**独占**的：`fastcgi_finish_request()` 只断开"客户端连接"，
+     *      **不会释放会话锁**。同一个人的下一个请求（刷新 / 点进读书 / 点别的页面）
+     *      会一路等到后台同步跑完 —— 于是"页面秒回、但下一个页面卡 9 秒"，
+     *      用户感觉就是"进读书页非常慢"。
+     *
+     *    ⚠️ 必须**两处**都放锁：
+     *      ① 关掉的这里（在 `fastcgi_finish_request()` **之前**）——
+     *         覆盖"本次是排同步的那个请求"。
+     *      ② 页面路由里、渲染**之前**（见 index.php 的 books 路由）——
+     *         因为后端的 shutdown 回调**不一定真的执行**（用户中断 / 服务器超时），
+     *         那时锁会一直挂到请求结束；提前放掉最稳妥。
+     *    放锁前要用的会话数据（familyId / personId）都在上方作为**参数**传进来了，
+     *    此后不再读 `$_SESSION`，所以放锁是安全的。
+     *    ⚠️ 读操作不受影响：放锁只影响"写"，而这里之后只做 HTTP + 写数据库。
      */
     public static function queueBackgroundSync(int $familyId, int $personId): void
     {
@@ -702,6 +729,12 @@ final class WeRead
         }
         self::$bgQueued[$personId] = true;
         register_shutdown_function(static function () use ($familyId, $personId): void {
+            // 🔴 v47：先放会话锁，再断连接 —— 顺序反了就没意义
+            //（`fastcgi_finish_request()` 会让 `session_write_close()` 变成 no-op 的时机
+            //  更早，所以锁必须在它之前放）。
+            if (session_status() === PHP_SESSION_ACTIVE) {
+                session_write_close();
+            }
             if (function_exists('fastcgi_finish_request')) {
                 fastcgi_finish_request();
             }