Simon Willison发布了一个名为 browser-compat-db 的GitHub项目，将Mozilla维护的 mdn/browser-compat-data 浏览器兼容性数据转换成约66MB的SQLite数据库，并通过GitHub仓库分支提供下载，还能直接用Datasette Lite在浏览器里探索。

这不是Mozilla官方发布的新兼容性数据库，也不是一个面向生产调用的实时服务。它更像一次工程化整理：把原本面向代码仓库、文档系统和近期MDN MCP服务的数据，整理成一个便携、可查询、可跨域加载的SQLite文件。对前端工具开发者和文档工程师来说，这类“小而稳”的数据形态，往往比多一个网页入口更实用。

项目把MDN数据从仓库形态搬进了SQLite

数据源来自Mozilla的 mdn/browser-compat-data 仓库。这是MDN生态中用于描述Web API、CSS、HTML等特性在不同浏览器中支持情况的基础数据，许多开发者平时在MDN页面上看到的兼容性表格，背后就依赖这类结构化信息。

Willison的工作不是重新采集兼容性结论，而是转换和分发。他用Claude Code for web（Opus 4.8）生成了构建脚本 build_db.py，并通过自己的 sqlite-utils 将数据写入SQLite。随后，Codex Desktop（GPT-5.5）帮助生成GitHub Actions工作流，用于构建数据库并推送到单独的 db orphan 分支。

这条链路里，AI的角色更接近代码助手，而不是数据可信源。兼容性判断仍来自Mozilla维护的数据仓库，脚本也需要人工理解和验证。把它写成“AI自动生成浏览器兼容数据库”，会误导读者。

项目原始形态这次变化直接影响
数据来源Mozilla mdn/browser-compat-data转换为SQLite文件便于用SQL和本地工具查询
构建脚本仓库数据处理代码Claude Code for web生成，sqlite-utils执行降低转换脚本编写成本
分发方式GitHub仓库文件推送到 db orphan 分支获得开放CORS，前端可直接加载
浏览方式需读JSON或接入工具Datasette Lite在线探索文档和数据人员上手更快

真正的关键不是SQL，而是开放CORS

这个项目最有判断力的地方，是没有把数据库只放到GitHub Releases。Willison提到，GitHub Releases不提供他需要的开放CORS头，而普通GitHub仓库文件可以。因此，最终数据库被放到 db orphan 分支，通过GitHub CDN下载，并能被Datasette Lite直接从浏览器端加载。

这解决的是一个前端工具常见但不显眼的问题：数据明明公开，却不一定能被网页应用直接取用。很多浏览器端工具不想架服务器，也不想为一个静态数据集维护API。一个带开放CORS的SQLite文件，配合Datasette Lite这类在浏览器内运行的查询工具，就能把“下载、浏览、检索”压缩成一个链接。

横向看，MDN新推出的MCP服务更适合AI开发工具在对话或代理场景中调用；npm包或JSON仓库更适合构建流程；SQLite文件则适合离线分析、文档审计、前端原型和小型内部工具。它们不是替代关系，而是服务不同工作流。

受影响的是工具作者，不是普通网页开发者

普通开发者查一个CSS属性能不能用，继续看MDN或Can I use就够了。这个项目更贴近两类人：一类是做Lint、文档站、代码搜索、IDE插件的前端工具开发者；另一类是需要批量分析兼容性数据的数据和文档工程师。

他们的实际收益很具体：不用自己解析一大堆仓库JSON，不用搭后端转发CORS，也不用把数据塞进临时脚本里反复清洗。约66MB的SQLite文件不算小，但仍在浏览器实验、离线分析和内部工具可接受的范围内。

限制也要讲清。这个仓库目前不能被当作官方API承诺来依赖，原文也没有给出固定更新频率、表结构稳定性或查询性能指标。接下来最该观察的，不是它会不会“颠覆”兼容性查询，而是三件小事：是否持续跟随Mozilla源数据更新，数据库结构是否保持可预期，前端工具社区是否愿意把它嵌入实际工作流。

如果这些条件成立，它会成为一个实用的数据中间层；如果维护中断，它也只是一次漂亮的转换实验。