配置校验

功能

• package.json：JSON 语法、包名规范（大写与空格会被 npm 直接拒绝）、版本号形式、依赖的版本范围，以及缺 license / description / repository
• `.env`：重复键（列出它出现的每一行，写三次就列三行）、键名里的点与连字符、空值、值上多余的引号
• ⚠️ `.env` 的键名大小写：不是全大写只给建议；而「除大小写外同名的两个键」（DATABASE_URL 与 database_url）升级为警告，并说明 Windows 会互相覆盖、Linux / macOS 是两个独立变量这一平台差异
• robots.txt：`Disallow: /` 挡整站、空 `Disallow:` 与它只差一个斜杠意思却相反、Sitemap 必须是绝对地址、缺 User-agent
• ⚠️ robots.txt 可以试着访问一个路径：填上路径与多个爬虫名（一行一个，也认逗号），逐个给出「允许 / 禁止」，并说明每个命中的是哪条规则、为什么它胜出（最具体的组胜、同组内最长匹配胜、等长时 Allow 胜、`*` 与 `$` 通配）
• sitemap.xml：命名空间声明、`<loc>` 必须是绝对地址、重复地址、5 万个地址与 50 MB 的上限
• ⚠️ sitemap 认两种根元素：`<urlset>`（列出页面）与 `<sitemapindex>`（列出别的 sitemap 文件）。根元素与子元素配错（索引里放 `<url>`、或反过来）会让搜索引擎一条都读不出来，所以单独报出来
• ⚠️ `.env` 能找出没被引用的键：把读它的代码粘进来，这里列出代码里从没出现过的键。它做的是一次文本搜索（按词边界匹配，所以 `DATABASE_PORT` 不会让 `PORT` 误判为「用过」）：`process.env.X`、`process.env['X']`、解构 `const { X } = process.env` 都认，但动态读法（`process.env[name]`、拼出来的键名）认不出来 —— 所以报了不代表一定没用，没报也不代表一定在用
• HTTP 响应头：已废弃的 X-XSS-Protection / Expect-CT / HPKP，以及缺失的 CSP、HSTS、nosniff 等安全头
• ⚠️ 结论分错误（会坏）/ 警告（能跑但多半不是你要的）/ 建议（可以更好）三级，并按这个顺序排
• ⚠️ `Access-Control-Allow-Origin: *` 配 `Allow-Credentials: true` 是浏览器直接拒绝的组合，报为错误
• ⚠️ 每条结论都说明「为什么」——不说「不合规」，说清不改会出什么事
• 自动识别贴进来的是哪种配置，也可以手动指定
• 全部在浏览器本地完成，不上传、不存储

使用方法

1. 把配置内容粘进去，类型会自动识别
2. 识别错了就在选项里手动指定
3. 按错误 → 警告 → 建议的顺序逐条看，每条都带「为什么」

常见问题

为什么要分成三级，而不是「通过 / 不通过」？

因为只给二元结论时，用户面对一堆红叉不知道该先修哪个 —— 于是干脆全都忽略，而那正是校验器失去意义的方式。分成三级之后，「错误」是这份文件会被拒的（JSON 语法错、`<loc>` 不是绝对地址、那个 CORS 组合、同一个键写两遍），「警告」是能跑但多半不是你要的（`Disallow: /` 挡住整站、除大小写外同名的两个环境变量键），「建议」是可以更好但不影响运行（缺 license、缺安全头、键名不是全大写）。按这个顺序排，第一眼就知道先动哪里。

为什么空着的 `Disallow:` 也算问题？

因为空值与斜杠只差一个字符，意思完全相反：`Disallow:` 表示不禁止任何东西，`Disallow: /` 表示禁止整个站点。这是 robots.txt 里最容易写反的一处，而写反的后果两边都不报错 —— 一边是搜索引擎安静地不来，另一边是测试环境忘了删、上线后再也没有自然流量。

为什么重复的环境变量键算错误，而不是提醒一下？

因为多数加载器（dotenv、Docker、systemd）取的是后一个，而写两次通常是想让某个值生效 —— 结果被编辑的那一处正好被忽略，排查时完全看不出来：文件里明明写着你要的值，程序读到的却是另一个。这是真实事故里排得进前几名的配置问题，所以按错误报，并列出这个键出现过的每一行（写三次就列三行）：只知道「重复了」不够，得知道删哪几处、改哪一处。

`DATABASE_URL` 和 `database_url` 明明是两个键，为什么报出来？

因为在 Windows 上它们不是两个键。Windows 的环境变量名不区分大小写，两个只差大小写的键会互相覆盖（谁生效取决于加载顺序）；而 Linux / macOS 上是两个各自独立的变量。也就是说，同一份 `.env` 在两种系统上行为不同 —— 本地（macOS）好好的，一上 Windows CI 就读到另一个值，这是最难排查的一类。所以它单独成一条警告，并把两个键各自的行号都点出来。它与「命名不是全大写」（只给建议，因为单独一个小写名在两种平台上都能用）是分开报的两件事。

「没被引用的键」会不会漏报或误报？

两者都可能，因为这一步做的是文本搜索，不是语法分析。它认 `process.env.X`、`process.env['X']`、解构 `const { X } = process.env`（键名都以文本出现）；但 `process.env[name]` 这种动态读法、或把键名拼出来的写法，它认不出来 —— 于是那个键会被列成「没被引用」，这是误报。反过来，键名出现在注释或无关字符串里也会被当成用过，这是漏报。所以「没报」不代表可以删、「报了」也不代表一定没用；把它当成一条线索，删之前全仓库搜一遍。

为什么依赖版本范围的检查这么宽松？

因为 `dependencies` 的值可以是 `workspace:*`、`file:../x`、git 地址、`npm:` 别名，也可能写成 `>=1.0.0 <2.0.0` 这样用空格并列的比较符。要把整套语法判完整得引入 semver 库，而这个检查的目标不是校验语义，只是挡住明显写错的（空字符串、`^abc`、`1.0.0.0`）—— 因为每一条结论都要用户去改配置，误报的代价是它失去可信度。

它会连我的密钥一起读走吗？

不会。全部在浏览器里完成，不上传也不存储。而且它只看语法与结构：一个 `API_KEY=` 后面的值是什么，与「这个键名合法吗、这个文件有没有重复键」完全无关，所以值的内容不参与任何判断。