Node.js读取本地日志失败的常见原因包括：工作目录错误、路径硬编码、编码不匹配（如GBK未转码）、正则解析未容错、CSV输出未规范转义；修复需用path.join动态拼路径、显式指定utf8编码、iconv-lite处理GBK、正则加if跳过脏数据、fs.writeFileSync写CSV、debugger调试。
Node.js 脚本读取本地日志文件失败：常见原因和修复
VSCode 本身不执行 Node.js 代码，它只是编辑器；真正运行脚本依赖你本地安装的 Node 环境和终端（如集成终端）。如果你在 VSCode 终端里执行 node parse-log.js 报错“Cannot find module”或“ENOENT”，大概率是路径或编码问题。
-
当前工作目录不对：VSCode 集成终端默认启动路径是打开的文件夹根目录，不是脚本所在目录。用
pwd（macOS/Linux）或cd（Windows）确认，必要时用process.cwd()在脚本中打印当前路径 -
日志文件路径写死但未适配系统：避免硬编码
C:\logs\app.log或/home/user/logs/app.log，改用path.join(__dirname, '../logs', 'app.log') -
日志含中文或特殊字符报
UnicodeDecodeError类似错误（实际是 Node 的encoding问题）：明确指定fs.readFileSync(filePath, { encoding: 'utf8' })，Windows 记事本保存的日志可能为gbk，此时需用iconv-lite转码
用正则从纯文本日志提取结构化字段：别过度设计
多数本地日志（如 Express、Winston 默认输出）是行式文本，每行一条记录，字段靠空格、方括号、冒号分隔。直接上 JSON.parse() 或第三方解析库反而容易崩——除非日志本身就是 JSON 格式（如 pino 输出）。
示例日志行：2024-05-20T09:12:33.456Z INFO [user-service] POST /api/login 200 124ms
- 用
String.prototype.match()提取关键字段比写完整语法分析器更稳：const match = line.match(/^(\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{3}Z) (\w+) \[([^\]]+)\] (\w+) ([^\s]+) (\d{3}) (\d+ms)$/) - 注意正则中的捕获组顺序要和后续数组解构一致，
match?.[1]是时间，match?.[5]是状态码 - 遇到格式不统一的混合日志（比如部分行缺响应时间），加
if (!match) continue跳过脏数据，别让整个脚本因单行异常中断
生成报表时选对输出格式：CSV 比 Excel 更可靠
在 Node 环境下生成 Excel（.xlsx）需要额外依赖（如 xlsx），且容易因权限、临时文件、内存占用出问题；而 CSV 是纯文本，用 fs.writeFileSync() 直接写入，VSCode 自带 CSV 预览支持，开发阶段足够用。
- 字段含逗号、换行或引号？必须用双引号包裹该字段，并将字段内双引号转义为两个双引号（
"→""），否则 Excel 会错列 - 第一行写表头，例如：
timestamp,status,endpoint,elapsed\n - 不要用
console.log()拼接 CSV 内容再重定向到文件——控制台输出可能被截断或编码混乱，始终用fs.writeFileSync(outputPath, csvContent, 'utf8')
在 VSCode 中调试日志解析脚本：别跳过 debugger
VSCode 的 Node.js 调试器能直接打断点看 match 结果、lines 数组长度、某一行的 line.length，比反复 console.log() 高效得多。
- 确保项目根目录有
.vscode/launch.json，内容包含"type": "node"和"program": "./parse-log.js" - 在脚本里想观察变量的地方插入
debugger;，按F5启动调试，VSCode 会自动停在该行 - 如果断点没触发，检查是否在“运行和调试”面板选择了正确的 launch 配置，且脚本路径没写错（比如误写成
./src/parse-log.js但实际在根目录）
日志格式千差万别，没有通用解析器；真正耗时的是确认你手头这份日志的稳定模式，而不是找一个“全自动报表工具”。先手动挑 10 行样本，用 VSCode 的查找（Ctrl+F）验证正则，再跑全量。
