e733c4f05711eace9c6e4c63fdf2d8c3392b6402
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 laoyang
|
b2b103df0f |
v68：修好日程「地点」的高德联想（v54 起静默失效）+ 账本四条动作路由
用户 2026-10-20：「网页端添加日程的时候，输入地点，应该调用高德接口，
获得准确的详细地址，现在这个功能不好用了，先修一下。」
## 根因不是 key、不是域名白名单 —— 是插件从来没被拉起来
`layout.php` 里 `fb-amap` meta 给的 SDK 地址**不带 `plugin`**，而加载器优先用它
⇒ `window.AMap.AutoComplete` **恒为 undefined** ⇒ 联想实例建不出来。
更糟的是 `addr_suggest.js` **一进函数就打 `data-addr-bound='1'`**，
于是"绑定失败"被记成"已经绑定过"，此后**再也不重试** —— 全链路静默，
界面上就是"输了字什么也不弹"。
（用真浏览器逐环量过才定位：key 有效、`inputtips` 真能返回 10 条候选，
问题全在我们自己这一侧。）
修法（双保险）：
- `layout.php` 新增 `needAutoComplete()`：SDK 到位后 `AMap.plugin('AMap.AutoComplete', cb)`，
超时也放行；启动顺序改成 **SDK → 插件 → 我们的脚本**。
- `addr_suggest.js` 就绪判据收紧成 `!!(AMap && AMap.AutoComplete)`；
`data-addr-bound` 改为 **new 成功之后**才打；新增 `ensurePlugin()`
并监听 `fb-amap-ready` 自愈（插件晚到也能接上）。
## 「准确的详细地址」
日程的地点**只有一栏**（`_event_fields.php` 只有 location），只把名字写回去，
回头要导航/找人还是查不到门牌。⇒ 地点框加 `data-addr-detail="1"`，
选中候选后写「名字 · 详细地址」（名字在前，人认的是名字），
并在这一行下面给一条「高德：省市区 · 门牌」提示。
⚠️ 提示行必须插在**整行之后**，塞进 `.mv-row` 会把 62px 标签列挤掉（v24 踩过）。
⚠️ 详细地址必须**延后一拍**写：AutoComplete 在 select 回调之后还会把 `poi.name`
塞回输入框，同步写会被它覆盖（第一版就因此白写）。
## 账本：服务端补四条路由
`Ledger::rename / setShare / unshare / shares / updateEntry / removeEntry`
**模型一直都有**，`ApiHandler::ledger()` 却只开了「建账本 / 记一笔 / 删账本」
⇒ 端上只能把「共享给谁」「账本名字」画成灰条，账目也改不了删不掉。
新增：`PATCH /ledger/<id>`（改名）、`/ledger/<id>/shares`（GET/POST/DELETE）、
`PATCH|DELETE /ledger/<id>/entries`（id 走 `Api::int('id')` ——
`Api::dispatch()` 只解析 3 段，`/ledger/3/entries/17` 的第 4 段会被丢掉）。
`Ledger::mine/find` 补 `is_owner`（`my_perm` 只有 read/write，分不出主人）；
改共享只允许主人（422）。
## 验证
- `familybook_push.sh` 全量流水线跑到 v47 停在 1 条失败：
「③ 选中候选后地点被换成规范地名」—— 因为这条旧契约是 `loc == '万象城 CGV'`，
而我们现在**有意**写成「名字 · 详细地址」。
⇒ 断言**升级**（不是放宽）：既要求名字在前、又要求门牌进来，比原来更严。
- `_fb_v47_addr_sim.py` 复验 **16 / 0**；
并做注入验证：把 `data-addr-detail="1"` 删掉 → ③ 立刻变红（证明断言真守着）。
- `_fb_v68_addr.py` 三模式 5/0（`--old` 拆掉两处时候选 0 条、`--one` 只拆 layout 仍 5/0）。
- 线上核对：`/api/v1/ledger/1/shares` 返回 **401**（不是 404，路由已生效）。
|
||
|
laoyang
|
32e9e9ab84 |
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()` / 不删。
|