根据报错信息定位原因，给出修复后的完整代码和分析。
编程 · 由 周野 维护（CPCX 撰稿人 · 编程与数据）
下面这段代码报错了，请帮我定位原因并给出修复后的完整代码，附上简要原因分析。 报错信息： 代码：
报错信息务必完整贴上，包括行号和完整堆栈——这是定位的关键线索，截掉一半 AI 只能靠猜。代码也不要只贴出错的那一行，把上下文相关的函数一起贴上，很多 bug 的根源其实在调用方。
拿到修复代码后别直接合入，先跑一遍确认，再问一句「还有哪些潜在原因会导致类似报错」，把同类问题一次排干净。
同一个报错，光给一行 message 和给「完整堆栈 + 依赖版本 + 触发步骤」是两种效率。堆栈里的文件名和行号是最有用的定位线索，依赖版本则能排除掉「升级后才出现」这类原因，两份都给上，AI 的定位会准很多。
如果问题只在特定环境下出现（本地正常、线上报错），把环境差异写进去：Node 版本、操作系统、是否容器内运行。
输入可以是这样：「Node 20 上跑 `npm run build` 报 `ERR_OSSL_EVP_UNSUPPORTED`，本地 Windows 正常，CI 的 Ubuntu 镜像报错，堆栈贴下面。」信息给到这个程度，AI 通常会直接指向 OpenSSL 3 与旧依赖的兼容问题并给出两种修法（升级依赖或加兼容参数），而不是让你逐个试。
完整输入应该包含三块：报错堆栈、代码、以及「什么时候会出现」。比如前端渲染列表时报 Cannot read properties of undefined (reading 'map')，代码是从 localStorage 取数据后直接 map，但该 key 从未写入过。
这种情况下它通常能一针见血：localStorage 里没有这个 key 时 getItem 返回 null，JSON.parse(null) 得到 null，对 null 调 map 就会报这个错。修复方案是给解析结果一个默认空数组，或者在使用前判空。
反过来，如果只贴一句报错、不贴代码，它只能列出一串「可能是数据结构不对、可能是接口返回为空」的猜测，你还得自己一个个验证——这部分时间是你自己省不掉的。
至少包含：完整报错消息、堆栈里属于你自己代码的那几行、出错的代码片段、运行环境（浏览器还是 Node、版本号）、以及能稳定复现的操作步骤。
框架版本尤其重要：同一个 API 在 React 17 和 18 下的行为差异足以让结论完全相反。如果你的问题是升级之后才出现的，把「升级前正常、升级后报错」这句话写进去，它给出的方向会完全不同。
偶发问题时，把「请帮我定位原因」改成「这是偶发问题，列出三个最可能的原因，并按排查成本从低到高排序，每条告诉我怎么验证」。偶发问题的关键不是直接给答案，而是给出可执行的排查顺序。
线上事故时，加一句「先给能在五分钟内止血的临时方案，再给根治方案」，把「先恢复服务、再复盘修根」两个层次分开，这一点在压力下特别重要。
适合已经有明确报错、且能稳定复现的问题：完整堆栈 + 相关代码 + 你试过什么，一次给全。
也适合报错信息看不懂、不知道该搜什么关键词的时候。