求助+讨论：AI生成代码的“隐形状态污染”困局-无报错数组变空，如何系统性解决？

我正在用AI辅助做Web应用，产品结构已经跑通，核心业务流程整走，但现在卡在一些看起来非常小的基础功能上，搞得有点郁闷。 问题现象 无致命红字：控制台没有未捕获的错误，也没有显着式的报错堆栈。 吞吐量突然变空：某个用于渲染列表的核心吞吐量，在几次用户交互后，不知不觉变成[]，但没有任何代码显式给它赋空值。 修改无效，甚至恶劣：我失败尝试了以下修复，问题都原样保留： · 改了重复的 DOM 结构，把可能冲突的内联 onclick 重构为事件委托 · 删除的函数实现，统一入口 · 重写了数据发送逻辑，增加请求序列号防止竞态 · 统一了媒体存储变量，全部收口到一个模块 ·“修A坏B”现象：上面的急做完后，不仅老问题没有消失，原来正常的另一个模块也开始出现类似的状态丢失。 ·难极复现：不是每次必现，但频率越来越高。就像一个幽灵处于随机污染状态。 我怀疑的可疑点： 1.全局变量被多处无保护 2.异步请求返回顺序不一致导致的竞态覆盖 3.页面生命周期（如切后台再、快速切换页面）触发多次绑定或事件总量 4.早期AI生成代码中大量.catch(() => {})静默吞错 5.某个地方深浅复制不当，导致引用了同一块内存却被意外清空 我想请教的是： 1、面对“无报错、状态被悄然篡改”的问题，你的一线排查流程是什么？你会如何一步步缩小包围圈？ 2、如何在不重写整个应用的前提下，快速建立这样的“状态污染的防御性监控层”？比如有没有比全量重构成Vuex/Pinia/Redux更轻量的临时方案？ 3、针对异步竞态和静默吞错，有没有什么反模式是我可以立即在代码库里 grep 并强制改正的？ 我隐约觉得，这类问题真正的解药，不仅仅是技术手段，而是一种工程约束和架构思维——那样的AI现在还给不了跑的东西。所以如果哪位前辈对此类问题有自己独到的看法，或者也曾在独立开发中踩过类似的坑，我非常期待向您学习，甚至如果您正在看机会，也欢迎私信我，我们可以聊聊有没有可能一起把这个项目从“跑通”走向“稳定”。