require('./config.json')会缓存，开发时应避免依赖；动态配置需用fs.readFileSync配合JSON.parse或jsonfile包，并配合VS Code JSON Outline验证结构。
require('./config.json') 会缓存，别在开发时依赖它
Node 的 require 加载 JSON 文件确实最简——一行代码就能拿到对象，但它的模块缓存机制会让后续修改完全不生效。你改了 config.json，再 require 还是旧内容，调试时容易误判问题根源。
这在本地开发、热重载或配置热更新场景下尤其危险。比如你正在调试一个根据 features 字段开关功能的逻辑，改完 JSON 却没反应，第一反应往往是代码错了，其实只是缓存没清。
- 仅限一次性读取、启动时加载的静态配置（如
package.json）可安全使用 - 涉及运行中动态读取、监听变更、或需多次 reload 的场景，必须换用
fs+JSON.parse - 若坚持用
require，需手动清缓存：delete require.cache[require.resolve('./config.json')]，但不推荐——易漏、难维护
fs.readFileSync 配合 JSON.parse 是最稳的同步方案
对大型 JSON 配置文件（比如 >500KB 或嵌套深度 >10 层），异步读取虽不阻塞主线程，但会把逻辑打散；而同步读取配合错误兜底，反而更可控、更易调试。
关键不是“同步好还是异步好”，而是“你是否需要立刻拿到结构化数据”。CLI 工具初始化、构建脚本预处理、VS Code 插件启动时解析配置，都属于必须同步拿结果的场景。
- 务必指定编码：
fs.readFileSync('./config.json', 'utf8')，否则返回Buffer，JSON.parse会报Unexpected token in JSON at position 0 - 包裹
try/catch：大型 JSON 常因 BOM 头、尾部逗号、注释残留导致JSON.parse报错，错误信息里position数字能快速定位坏行 - 避免直接
fs.readFileSync('./config.json')—— 没编码参数时返回Buffer，JSON.parse会静默失败或抛奇怪错误
重构大型 JSON 时，先用 jsonfile 替代裸 fs
原生 fs 写 JSON 容易丢格式、缺缩进、BOM 头污染、写入失败无提示。当你需要频繁修改 tsconfig.json、jest.config.json 或自定义 schema 配置时，jsonfile 是更少出错的选择。
它默认处理 UTF-8 BOM，支持 spaces: 2 美化输出，且 writeFileSync 失败时会抛明确错误（而非静默失败），这对重构阶段验证结构合法性很关键。
- 安装：
npm install jsonfile - 读取：
jsonfile.readFileSync('./config.json')—— 自动跳过 BOM，不用手动JSON.parse - 写入：
jsonfile.writeFileSync('./config.json', newData, { spaces: 2 })—— 保证换行和缩进，diff 更干净 - 注意：不要用
jsonfile.readFile异步版处理大文件，V8 堆内存可能溢出；优先选同步 API
VS Code 中配合树状视图插件做结构验证
光靠代码读写不够，大型 JSON 重构后是否仍符合 schema？字段名有没有拼错？层级有没有意外塌陷？这些靠肉眼或 console.log 几乎没法验。
装一个支持树状导航的 JSON 插件（如官方 JSON 支持或 vscode-json），打开配置文件后点侧边栏的「JSON Outline」，能立刻看到所有 key 的嵌套路径、类型、数组长度。比滚动几千行找 "apiEndpoints" 快得多。
- 右键某个节点 → “Rename Key” 可批量改键名，自动同步到源码，避免手抖漏改
- 展开后若某层显示
[object Object]而非具体字段，说明该处 JSON 有语法错误（比如多逗号、单引号） - 对比重构前后两个 JSON 文件的 Outline 树，能一眼看出新增/删减的顶层字段，比 diff 工具更直观
