报错日志

Error Log

也常被叫作：报错信息错误日志控制台报错堆栈

验收与证据通常止于「运行时」约 1 分钟读完

你可能会这么说

「屏幕上一堆红字，我完全看不懂，只能整段复制给 AI。」

报错日志 Error Log

程序出错时留下的原始记录，通常第一行就写着原因，剩下的是它经过的路。

红字看起来吓人，但结构很简单：第一行是错误类型和原因，下面一长串是调用路径（谁调了谁）。 你只要看两样东西——第一行说了什么，以及路径里第一个属于你自己项目的文件（而不是 node_modules 或框架内部）。那个文件通常就是问题所在。

几个高频类型认一下就够用：undefined is not a function / Cannot read properties of undefined 是「你以为有的东西没有」；404 是「路径找错了」；500 是「服务器自己炸了」；CORS 是「浏览器不允许跨站请求」；ECONNREFUSED 是「对方根本没在听」。

也是真事。我们在给一个本地图像生成工具做家用启动脚本时，在发给它的任务 JSON 顶层加了一个注释键，想着方便读配置。结果整个请求被原样拒绝。第一反应是「工具坏了」，直到把完整报错贴出来逐行看——它说得清清楚楚：顶层只允许节点 ID 键，多出来的那个键名字就写在报错里。这个错后来写进了我们的规则：API 的 JSON 顶层不放任何说明性内容。

如果当时只概括成「提交任务失败」，这层信息就丢了。报错的原文里几乎总是写着答案，概括等于扔答案。

还有件容易忽略的事：报错也可能不在你看的地方。浏览器控制台管前端，服务器日志管后端。页面白屏但控制台干净，多半要去看后端日志。

长什么样真实可交互，不是截图

TypeError: Cannot read properties of undefined (reading 'name')
    at UserCard (src/components/user-card.tsx:14:22)   ← 你的文件，从这看
    at renderWithHooks (node_modules/react-dom/...)     ← 框架内部，先跳过
    at mountIndeterminateComponent (node_modules/...)

第一行说了原因：想读 undefined 的 name

第一个自己的文件说了位置：user-card.tsx 第 14 行

有这两条信息，问题基本已经定位了一半。下面那些 node_modules 的行几乎永远可以先跳过。

拆开看，里面有这几块

1
错误类型 Error type
TypeError、SyntaxError、NetworkError…告诉你是哪一类毛病。
2
错误消息 Message
第一行的人话部分，通常直接说了原因。
3
调用栈 Stack trace
从出错点往上追的路径。只看第一个属于你项目的文件。
4
位置 File:line:col
文件名 + 行号 + 列号。定位就靠它。

常见的有哪几种

浏览器控制台DevTools console

前端报错在这儿。F12 打开，看 Console 和 Network 两栏。

用在：页面白屏、点了没反应、样式错乱

服务器日志Server log

后端报错在这儿，浏览器里看不到。

用在：接口 500、数据没保存、登录失败

构建日志Build log

编译阶段的错误，最容易修，因为它在最早的位置就拦住了你。

用在：部署失败、命令跑不动

警告Warning

黄字。不一定要立刻处理，但别长期无视——很多线上问题先以警告出现过。

用在：功能正常但有黄字时

容易搞混？这样区分

报错日志 ≠ 复现步骤 Reproduction steps

日志是机器留下的证据，复现步骤是人能重放的过程。判断方法：日志回答「哪里炸了」，复现步骤回答「怎么让它再炸一次」。

看复现步骤

报错日志 ≠ HTTP 状态码 HTTP status code

状态码是请求层面的结果（404、500），报错日志是程序内部的细节。看到 500 说明服务器出错了，但为什么出错，只能去服务器日志里找。

什么时候用得上

页面白屏

先 F12 看 Console 第一条红字。90% 的情况那一行就够定位。

点了没反应

看 Network 栏：请求发出去了吗？返回了什么状态码？

本地好线上坏

去服务器日志，别在本地反复猜。两个环境的差别通常在环境变量或路径上。

你可以这样跟 AI 说

直接复制下面这段，把【】里的换成你的情况。它比一句「帮我加个 X」多说清楚了：改哪里、不许动啥、做完交什么。

程序报错了，完整报错原文如下（我没有做任何删减）：

```
[把整段报错原样粘在这里，包括所有行]
```

【环境】[浏览器/手机、线上还是本地、什么操作触发的]
【复现步骤】[1. 2. 3.]

请按这个顺序回答，先不要改代码：
1. 这段报错的第一行在说什么（用大白话）
2. 出问题的位置是哪个文件、第几行
3. 最可能的原因是什么，你的依据是这段报错里的哪一句
4. 有没有可能是别的原因，怎么区分

我确认之后你再动手改。改完请告诉我怎么复现验证，以及这段报错应该会变成什么。

要求它「指出依据是报错里的哪一句」，能有效防止它凭经验猜一个常见原因、然后改错地方。

它说「做好了」，你怎么自己验

这是本站的重头戏。AI 最会的不是写代码，是说「已完成」。这一条，它通常最多做到「运行时」这层：真的跑起来了，能在本机看到结果。

要亲眼看到这些，才算数

它指出的文件和行号，和报错原文里写的一致（自己对一眼，不用懂代码）。
它的原因解释能对应到报错原文里的具体某一句，不是泛泛的「可能是数据问题」。
改完后重新触发同一个操作，那段报错消失了——不是换成另一段报错就算完。
确认控制台里没有新增的其他红字（修一个引入两个是常见结果）。

它常这么糊弄你

它说「这是常见问题，通常是 xxx 导致的」，但没有引用你贴的报错里的任何一句——很可能在套模板。
「已修复」但报错只是被藏起来了（比如加了 try-catch 什么都不做）。要问：原因解决了，还是错误被吞了？
只看了你概括的那一句「有个报错」就开始改。概括本身就丢了答案。
报错还在，但页面看起来正常了，于是宣布修好。红字不会自己变成无害。

读日志能到「运行时」层：你重新触发一次，亲眼确认那段报错消失了。

考考你选一个你觉得对的

遇到一长串报错，最有效的看法是？

想再深挖一点靠谱出处

Log file（日志文件）Wikipedia ↗console（浏览器控制台 API）MDN ↗

# 报错日志 (Error Log)

> 程序出错时留下的原始记录，通常第一行就写着原因，剩下的是它经过的路。

**你可能会这么说**：屏幕上一堆红字，我完全看不懂，只能整段复制给 AI。

红字看起来吓人，但结构很简单：**第一行是错误类型和原因，下面一长串是调用路径（谁调了谁）。** 你只要看两样东西——第一行说了什么，以及路径里第一个属于**你自己项目**的文件（而不是 node_modules 或框架内部）。那个文件通常就是问题所在。 几个高频类型认一下就够用：undefined is not a function / Cannot read properties of undefined 是「你以为有的东西没有」；404 是「路径找错了」；500 是「服务器自己炸了」；CORS 是「浏览器不允许跨站请求」；ECONNREFUSED 是「对方根本没在听」。 也是真事。我们在给一个本地图像生成工具做家用启动脚本时，在发给它的任务 JSON 顶层加了一个注释键，想着方便读配置。结果整个请求被原样拒绝。第一反应是「工具坏了」，直到把完整报错贴出来逐行看——它说得清清楚楚：顶层只允许节点 ID 键，多出来的那个键名字就写在报错里。这个错后来写进了我们的规则：API 的 JSON 顶层不放任何说明性内容。 如果当时只概括成「提交任务失败」，这层信息就丢了。**报错的原文里几乎总是写着答案，概括等于扔答案。** 还有件容易忽略的事：报错也可能不在你看的地方。浏览器控制台管前端，服务器日志管后端。页面白屏但控制台干净，多半要去看后端日志。

**也叫**：报错信息、错误日志、控制台报错、堆栈

## 你可以这样告诉 AI

```text
程序报错了，完整报错原文如下（我没有做任何删减）：

```
[把整段报错原样粘在这里，包括所有行]
```

【环境】[浏览器/手机、线上还是本地、什么操作触发的]
【复现步骤】[1. 2. 3.]

请按这个顺序回答，先不要改代码：
1. 这段报错的第一行在说什么（用大白话）
2. 出问题的位置是哪个文件、第几行
3. 最可能的原因是什么，你的依据是这段报错里的哪一句
4. 有没有可能是别的原因，怎么区分

我确认之后你再动手改。改完请告诉我怎么复现验证，以及这段报错应该会变成什么。
```

## 怎么验证他真的做到了

通常止于层级：**运行时** — 真的跑起来了，能在本机看到结果

- [ ] 它指出的文件和行号，和报错原文里写的一致（自己对一眼，不用懂代码）。
- [ ] 它的原因解释能对应到报错原文里的具体某一句，不是泛泛的「可能是数据问题」。
- [ ] 改完后重新触发同一个操作，那段报错消失了——不是换成另一段报错就算完。
- [ ] 确认控制台里没有新增的其他红字（修一个引入两个是常见结果）。

常见糊弄：
- 它说「这是常见问题，通常是 xxx 导致的」，但没有引用你贴的报错里的任何一句——很可能在套模板。
- 「已修复」但报错只是被藏起来了（比如加了 try-catch 什么都不做）。要问：原因解决了，还是错误被吞了？
- 只看了你概括的那一句「有个报错」就开始改。概括本身就丢了答案。
- 报错还在，但页面看起来正常了，于是宣布修好。红字不会自己变成无害。

来源：https://mickerbook.com/reference/t/error-log/