现象#

第一轮审查报告说输入校验缺失——空字符串能通过。修复时改了 chat/schemas.py 的校验逻辑，跑测试也通过了。

但第二轮 reviewer 报告：问题依然存在。

原因#

前端请求实际走的是 BFF 层的 mvp/schemas.py，不是直接打到 chat/schemas.py。BFF 层有自己的 schema 定义，请求在这一层就被序列化/转发了，根本不会触达 chat 层的校验。

教训#

改代码前先确认请求实际经过哪些层。 不要凭文件名猜——chat/schemas.py 听起来像处理聊天的入口，但架构里它可能只是内部模块。

快速确认方法：

1
# 给目标函数加个 print/log，然后发请求看哪个文件的日志先出现
2
grep -rn "class MessageInput" src/

现象#

第三轮修复了 token 过期检测逻辑。代码确实改了，PR 也合了。但 reviewer 验证时行为和修复前一模一样。

原因#

后端进程没有重启。热更新只覆盖前端，Python 后端跑的还是旧代码。

教训#

修复后端代码后的验证清单：

1. 确认部署/重启完成（不是只 git pull）
2. 检查进程启动时间：ps aux | grep uvicorn 看时间戳
3. 加一个临时 log 确认新代码在跑

现象#

修复了”token 过期后前端不跳登录”的问题——方案是检测到 401/403 就清除本地 token 并跳转登录页。

内部审查时发现：付费墙和角色锁定功能全部被破坏了。

原因#

403 Forbidden 有多种语义：

• token 过期/无效 → 应该清 token
• 无权限（未付费、角色不匹配）→ 不应该清 token，用户登录态完全正常

一刀切把 403 也当作”需要重新登录”处理，把正常的 paywall 拦截变成了无限登录循环。

正确做法#

1
// ❌ 错误
2
if (status === 401 || status === 403) clearTokenAndRedirect()
3

4
// ✅ 正确
5
if (status === 401) clearTokenAndRedirect()
6
if (status === 403) showPermissionDenied() // 不碰 token

如果后端确实存在”token 过期但返回 403”的历史遗留，应该修后端的状态码，不是前端模糊处理。

现象#

第五轮修复了后端路由层的错误信息（从英文改为中文）。重启了进程，但 reviewer 看到的还是英文错误。

原因#

Python 的 .pyc 编译缓存。即使 .py 源文件更新了，如果 .pyc 时间戳或内容没有正确失效，解释器可能仍然加载旧的字节码。

教训#

部署 Python 后端修复时：

1
# 清除所有 .pyc 缓存
2
find . -type d -name __pycache__ -exec rm -rf {} +
3
find . -name "*.pyc" -delete
4

5
# 然后再重启
6
systemctl restart myapp

或者在启动脚本里加上环境变量禁用 bytecode cache：

1
export PYTHONDONTWRITEBYTECODE=1