Evidence 是开源的“代码即 BI”（BI as Code）框架，用 SQL+Markdown 构建报告、仪表盘与数据应用，基于 Git 版本控制；核心框架 MIT 许可免费，Evidence Cloud 托管 $15/用户/月起。 定价：开源免费；Cloud Team $15/用户/月起。编辑评分：⭐ 4.8。
Evidence.dev是什么？
简单说，Evidence.dev 是一个让你用 SQL + Markdown 写数据分析报告的开源工具。你不需要折腾复杂的 BI 平台，也不需要学什么新语言——你只要会写 SQL 查数据库，然后用 Markdown 把结果写成报告，再加上一些图表、表格，就能生成一个交互式的静态站点。整个过程像写代码一样，用 Git 做版本管理，改起来也方便。
它本质上是个“数据文档”工具，把数据查询、可视化和文档放在一个项目里。你跑一次 SQL，数据就被抓成静态文件，报告就生成了。部署可以扔到 Vercel、Netlify 这类平台，团队里谁都能直接看。
核心功能
#### 1. SQL 查数据 + Markdown 写报告
这是最核心的玩法。你在一个 .md 文件里写 Markdown，中间嵌入 SQL 查询块，Evidence 会在构建时执行这些 SQL，然后把结果渲染成表格或图表。比如你想做一个销售趋势报告，直接写个 ```sql SELECT date, revenue FROM sales ``，后面接 ``markdown `` 就完事。学习成本极低，只要你会 SQL 和基础 Markdown，几乎零磨合。
#### 2. 交互式图表和表格
内置了常见的可视化组件：折线图、柱状图、散点图、地图、表格等。图表默认带交互——鼠标悬停显示数值、排序、筛选。你不需要额外写前端代码，所有组件都以 Markdown 标签的形式调用，比如 。实际用下来，日常分析报告 90% 的场景都能覆盖，而且图表风格简洁，直接可用。
#### 3. Git 版本控制 项目本身就是纯文本（SQL + Markdown），天然适合 Git。每个报告版本、每次修改都能追溯，团队协作时不会出现“谁改了我的图表”的混乱。对于注重数据报告质量和可复现的团队来说，这是非常扎实的基础能力。你可以像管理代码一样管理数据报告。
#### 4. 部署为静态站点 构建后生成静态 HTML/CSS/JS 文件，可以部署到 Vercel、Netlify、GitHub Pages 之类的平台。不需要服务器，不需要维护数据库连接（因为数据在构建时已经被抓取和序列化）。部署后就是一个个可分享的页面，团队成员或客户只需要浏览器就能查看。对于写周报、月报、项目复盘这类场景，比发邮件或 PDF 方便得多。
#### 5. 多数据源支持 支持连接 PostgreSQL、DuckDB、Snowflake、SQLite，甚至直接用 CSV 文件。所以无论是数据仓库、本地数据库还是随手导出的 Excel 表格，都能用 Evidence 来生成报告。灵活性不错，特别是 DuckDB 这种轻量级嵌入式数据库，配合作小数据集分析很顺手。
版本/套餐对比
Evidence 目前是开源工具，核心功能全部免费。它的代码仓库在 GitHub，你可以自行下载、部署、二次开发，没有任何功能限制。
| 版本 | 费用 | 说明 |
|---|---|---|
| 开源版（社区版） | 免费 | 所有功能全开，无限制。部署在自己服务器或第三方静态托管。 |
| 云托管服务（如果有） | 暂未公开 | 目前官方主要提供开源版本，未来可能推出云托管或企业版，具体以官网为准。 |
实际使用中，绝大多数用户用开源版就够了。
值不值得用？
优点：
- 学习成本极低，SQL + Markdown 人人会用，新人上手快。
- Git 原生支持，数据报告可版本化、可协作，这一点比主流 BI 工具强。
- 部署灵活，静态站点模式不需要运维，适合团队快速共享分析结果。
- 图表组件够用且交互良好，省去了写前端代码的麻烦。
缺点：
- 有 SQL 门槛，不会 SQL 的人完全没法用，这限制了受众。
- 不支持实时数据。因为是静态生成，数据是一次性快照，做不了实时监控或 dashboard。如果需要实时刷新，得配合其他工具来做增量更新，比较复杂。
- 处理大数据集吃力。构建时在内存中执行查询，数据量过大（比如几亿行）会慢甚至崩溃。官方建议对大表做聚合、采样后再用。
总体结论：如果你日常工作是写 SQL 做分析报告，并且报告不需要实时更新，那 Evidence 是非常趁手的工具，值得一试。它不完美，但把“SQL 查数 + Markdown 写文档”这个场景做到了极致。
使用建议
- 用 DuckDB 做本地测试：DuckDB 轻量且不依赖网络，配合 CSV 或 Parquet 文件，可以快速跑通全流程。
- 数据量大的情况，先聚合再使用：在 SQL 里先用 GROUP BY
汇总，或者从数据库里抽样，避免直接拉全量数据。 - 用 Git 分支管理报告：比如每个版本一个分支，主分支保留最终发布版，开发分支做修改，合并前 review 一下 SQL 正确性。
- 部署到 Vercel 或 Netlify：绑定 GitHub 仓库后自动部署，每次 push 自动构建新报告，连手动操作都省了。
- 用 ` 组件组织长报告：如果报告内容很多，可以把详细数据折叠起来，只展示摘要，读者按需展开。
适合谁用？
推荐：
- 数据分析师、数据运营、业务分析人员，日常用 SQL 写周报/月报。
- 需要做数据文档的团队（比如产品数据看板、项目复盘、AB测试报告）。
- 习惯用代码和 Git 工作流的技术团队。
可考虑：
- 数据工程师：用来快速生成数据质量报告或元数据文档。
- 管理者：只需要看别人生成的报告，自己不写 SQL 的话可以只做读者。
不推荐：
- 完全不会 SQL 的业务人员（建议用 BI 工具或 Excel）。
- 需要实时更新的数据监控场景（比如大屏、运营大盘）。
- 数据量极大且无法做聚合的场景（建议考虑专业 BI 或 OLAP 引擎）。
