做JSON Lint价值在哪？
JSON Lint 讨论的是「团队愿不愿意长期维护这份文本」：能 `parse` 的 JSON 仍可能含重复键、混用字符串与数字表示同一枚举、或把大整数塞进 number 造成静默精度损失。对外招标文件、渠道 openapi 样例、给实习生的习题，如果写法随意，后续每一次复制都会放大技术债。在线 JSON Lint 在语法通过后再扫一遍风格与可疑模式，帮你在邮件发出去之前先经历一次「挑剔同事」的预演。它与 JSON 校验是递进关系：校验回答「机器吃不吃」，Lint 回答「半年后的人还愿不愿意吃」。Ai2Done 把流程放在浏览器里，方便市场与项目负责人在不装 CLI 的前提下，把交付物打磨到更职业的形态。
如何把 JSON Lint 当作对外样例发布前的最后一道体面检查
- 先跑严格语法校验，直到零错误；再在 Lint 模式查看警告列表，按「阻塞 / 建议」分类，不要一上来就争论业务含义。
- 对重复键、可疑数字精度、空字符串与 null 混用等警告，逐条对照团队 JSON Style Guide；若无文档，可先在评审群达成三条最低共识写进 Wiki。
- 将清理后的样例连同「已跑 Lint 截图」附在发布单上，便于审计；若警告被有意忽略，请在备注写明业务理由与风险接受人。
JSON Lint 常见问题
JSON Lint 和 JSON Schema 校验是不是一回事，我在对外接口文档里应该要求合作方做到哪一层？
Lint 多关注文本层面的可疑模式，Schema 才约束字段集合、类型与必填；对外合同应至少要求「语法正确 + Schema 通过」，Lint 可作为附加质量分，不要混用术语以免验收争议。
Lint 报告里提示重复键，但 JavaScript 对象字面量本来就会覆盖，为什么这在 JSON 交付里仍算高风险？
JSON 解析器对重复键的处理在不同语言里并不完全一致，有的保留后者、有的保留前者；跨语言系统对接时这属于定时炸弹。应在源头去重并加单元测试，Lint 只是提醒你「这里曾有人偷懒」。
我们内部配置允许 JSONC 带注释，Lint 却一直报错，我该如何在工具链里区分对内宽松与对外严格？
在仓库里用不同扩展名或构建步骤：`.jsonc` 走宽松解析，发布脚本再 strip 注释输出 `.json`；在线 Lint 页面只检验对外文件，避免用同一规则卡死内部草稿。
Lint 警告我把金额写成 number，可财务同事坚持要参与运算，这条规则到底听谁的才不耽误上线？
若金额可能超过安全整数范围，应改为字符串并配合 decimal 库；需写清「对外序列化格式」与「对内 runtime 类型」两层模型。Lint 的价值是逼你在评审里显式选择，而不是上线后让 CFO 在报表里发现一分钱误差。
我想把 Lint 集成进 CI，在网页里点的结果和流水线里跑的结果会不一致吗，该如何对齐规则集？
不同引擎规则集版本可能不同；应锁定同一 npm 包或同一二进制版本，并把规则文件检入 Git。网页端可作为本地预检，最终以 CI 报告为准，避免「我网页上绿了但流水线红了」的双面叙事。