0. 连续五次失败，但这不是 flaky
我有一条每夜跑的 E2E：起一套完整的 compose（MySQL、Redis、所有服务），然后用 Playwright 跑管理后台的关键路径。
Engineering Notes
孟斌的小站
技术博客与学习记录
0. 两次看起来相反的判断
这篇讲两个性能决策，它们的结论看起来是相反的。
0. 这篇是给"想照抄这套结构"的人写的
前面 24 篇讲的是"我为什么这么做"。这一篇不一样——它讲具体怎么做。
0. 症状：服务端很快，但页面就是慢
有一段时间我觉得管理后台"卡"。具体表现是：点侧边栏切到 /dashboard、/usage、/admin/logs，要等大约一秒才出内容。
0. 我给自己做了一次代码审查，然后否决了它的大部分方案
有一阵子我觉得代码里积了不少问题——文件越来越大、有几处逻辑我自己都记不清了。于是我让一个模型对 develop 做了一轮系统性审查，产出一份问题清单。
0. 一个差点被我当成"样式问题"的许可证问题
这次重设计的起点不是"界面不好看"，是一件更实际的事：字体没覆盖中文。
0. 这个页面的难点不在聊天界面
做一个"在浏览器里调模型"的 Playground，聊天界面本身没什么难的：一个输入框、一个消息列表、一个流式渲染。
0. 第一版对账：全是误报
我第一版的对账逻辑很简单：把钱包余额和账本净额比一下，不一致就报出来。
0. 差点发生的事：审计日志一条都没记
这段代码注释是我在 review 自己的时候发现的，编号 platform-L9：
0. 两个现象，一个共同的形状
这篇复盘两次问题。它们表面上看没有关系：