别被INFO日志骗了：trae-novel项目里3个排查坑与上线清单

别被INFO日志骗了：trae-novel项目里3个排查坑与上线清单

2026年7月21日上午，trae-novel的测试环境弹出一条看着平平无奇的INFO日志：2026-07-21 11:27:30,587 - app.common.logger - INFO - A…。这种级别的打印一天能刷好几屏，我当下没当回事。直到压测跑起来，接口开始返回异常，顺着这条日志往回挖，前前后后花了三轮优化、修了两处同模式的问题，最后还顺手整理出一份上线前能直接照着走的检查清单。回头看，那条"正常"日志坑得最深的地方，恰恰是它太像正常日志了。

第一轮差点栽在"修一个漏一片"上。顺着链路定位到 /api/ai/quick-summarize 接口，根因是它的JSON解析逻辑字段映射写错了，解析失败只打了条INFO。我第一反应是把这个单点改掉，单接口验证也过了。可压测时同样的问题又冒出来——一查才发现，同一个JSON解析工具类被同架构的 /api/bestsellers/analyze-trend 接口共用着，工具类的毛病没动，等于只补了一个窟窿，其他用它的接口照样漏。这次我把所有用到这个解析工具类的接口逻辑一起改了，压测通过才收尾。

第二轮碰上的是个"现在动不如先别动"的取舍。theme_tracker（主题追踪模块）里也有类似的解析逻辑，但改动会牵动核心主题初始化的部分，当前版本业务影响面极小，测试阶段也没复现过报错。贸然改，反而可能引入新的稳定性问题。我没硬上，而是给这个模块打了风险标记，把"后续优先解析 reasoning_content 字段"明确写进迭代待办、定了跟进时间点，另外针对它整理了一份最小验证清单，把"主题初始化时解析逻辑正常、异常场景能降级不报错"列为必验项。既避开了当下的风险，也没让这事石沉大海。

最后一轮才把 theme_tracker 的加固真正落地：统一了所有JSON解析模块的字段优先级，确保优先解析 reasoning_content，后面再出现同类解析问题就少一层隐患。

整个排查里那些容易出岔子的路径，我收尾时压成了一页上线前验证清单，四条核心路径是：/api/ai/quick-summarize 接口验证、/api/bestsellers/analyze-trend 接口验证、章节生成质量检查、主题初始化验证，每条下面都列了最小验证项。下次上线前照着过一遍，这次挖出来的风险点基本就全覆盖了。

说到底，这次最值钱的不是修完那几个接口，而是把一次性的排查沉淀成了能反复用的东西。单点异常别急着改代码，先扫一遍同依赖、同架构的模块，能省掉一大半重复劳动；评估后暂不动的高风险模块，必须打标记、进待办、定时间点，查完就忘是大忌；临时排查出的问题点和验证项，最好直接固化成上线checklist——查一次，管很久。