Code Review：fix(fsBridge): guard readFile against oversized files exceeding V8 string limit (#1934)

变更概述

本 PR 在 ipcBridge.fs.readFile 中添加了 256MB 的文件大小检查，防止读取超大文件时触发 V8 RangeError: Invalid string length 崩溃（Sentry ELECTRON-D3）。超大文件返回 null，行为与 ENOENT/EBUSY 一致。共修改 3 个文件：实现文件 1 个、单元测试 2 个。

方案评估

结论：✅ 方案合理

在 readFile 前先执行 fs.stat 检查文件大小是处理此类问题的标准做法。返回 null 与现有 ENOENT/EBUSY 的处理语义保持一致，上层调用方无需单独处理新的错误类型。256MB 阈值为 V8 ~512MB 字符串上限的一半，留有充足余量。测试覆盖了关键路径，包括 stat 失败、超大文件和正常读取场景。

问题清单

🔵 LOW — console.warn 残留在生产代码中

文件：src/process/bridge/fsBridge.ts，第 348 行

问题代码：

console.warn(`[fsBridge] File too large to read as text (${stat.size} bytes): ${filePath}`);

问题说明：项目规范要求生产代码中不使用 console.log/console.warn，应使用项目统一的日志机制。当前已有 console.error 在同文件中大量存在（历史遗留），属于已知问题，但新代码不应延续该模式。

修复建议：若项目暂无统一 logger，可直接删除该行（文件路径已在 filePath 中，信息仍可从 stat.size > MAX_READ_FILE_SIZE 分支推断），或等待统一 logger 引入后再添加。

🔵 LOW — 缺少 stat 抛出 EBUSY 时的测试用例

文件：tests/unit/process/bridge/fsBridge.readFile.test.ts

问题说明：当前测试覆盖了 fs.stat 抛出 ENOENT 的情形（mockStat.mockRejectedValueOnce ENOENT → null），但未覆盖 fs.stat 抛出 EBUSY 的场景。实现中 catch 块会正确处理（code === 'EBUSY' → null），但缺乏测试保证。stat() 抛出 EBUSY 在 Windows 上是可能的（例如文件正被独占锁定）。

修复建议（可选，不阻塞合并）：

it('readFile returns null when stat throws EBUSY', async () => {
  await setupProviders();
  const readFileCb = providerCallbacks['readFile'] as (args: { path: string }) => Promise<string | null>;

  mockStat.mockRejectedValueOnce(makeErrnoError('EBUSY', 'EBUSY: resource busy or locked'));

  const result = await readFileCb({ path: '/locked/file.db' });
  expect(result).toBeNull();
  expect(mockReadFile).not.toHaveBeenCalled();
});

汇总

结论

✅ 批准合并 — 仅有两个 LOW 级问题，均不阻塞合并。实现正确、简洁，测试覆盖充分，方案与现有架构一致。

本报告由本地 pr-review skill 生成，包含完整项目上下文，无截断限制。

CONCLUSION: APPROVED
IS_CRITICAL_PATH: false
PR_NUMBER: 1934

✅ 已自动 review，无阻塞性问题，正在触发自动合并。