C# + Scriban 做静态站点生成（对标 baifenwei 的 generate_site.py）

Scriban 是 .NET 生态下高性能模板引擎，语法类似 Liquid / Jinja2，刚好用来替代 Python Jinja2，写一个 C# 控制台程序（GenerateSite.exe），盘后一次性：

1. 从数据库读取算好的估值、百分位数据
2. 加载 html 模板（支持布局继承：shared_base_style + page_style）
3. 批量渲染，输出静态 html 到 dist/ 目录
4. 同时复制静态资源（js/css/ECharts）
5. dist 目录直接丢到 Cloudflare Pages / 对象存储，不需要运行 Web 服务

整个程序就是一个控制台工具，对应 baifenwei 的 generate_site.py。

https://baifenwei.com

💥💥💥💥💥💥

C# + Scriban：生成 HTML 报表，自动发邮件（MES / 生产报表场景）

这个组合非常适合工厂场景，完整链路：

C# 读取 MES 数据库 → 计算指标（OEE、良率、产量）→ Scriban 渲染 HTML 报表模板 → 得到完整 HTML 字符串 分支两个用法：

1. 保存成 .html 文件归档（存入文件服务器）
2. 直接把 HTML 当做邮件正文，发送带样式图表的邮件报表

重点：不需要生成静态站点整套 dist 目录！ 你只需要渲染单份 HTML 字符串，不需要输出文件也可以直接塞进邮件。当然也可以同时输出 HTML 文件作为附件。

💥💥💥💥💥💥💥💥💥💥💥

核心原因：确实很少人用 C# + Scriban 做 SSG，不是它不行，是生态习惯、历史选型、人群圈子共同造成的，并不是技术缺陷。

先说结论：小众 ≠ 不靠谱。只是属于.NET 圈子里的 “非主流 SSG 方案”，但对你这个估值看板场景非常合适。

一、为什么很少人用 C# + Scriban 做静态网站生成

1. SSG 领域主流是 JS/PHP/Python，不是 .NET

静态站点生成这个赛道，最早、最火的工具都是 JS 生态：

• Hugo(Go)、Jekyll(Ruby)、Hexo/VitePress(JS)、Pelican(Python)
• 量化 / 数据看板圈子，大家天然优先 Python：采集库、pandas 随手就能算指标，然后用 Jinja2 生成页面。就是 baifenwei 那条路线。

.NET 开发者本来就很少去做 “静态网站生成” 这件事。 .NET 圈子的传统思维：

要做网站 → 直接上 ASP.NET（Razor Pages / MVC），写动态网页。 很少会想到：我写一个控制台程序，预渲染全部静态 HTML 丢到 CDN。

2. .NET 内部有自己的 SSG 工具，Scriban 只是底层模板引擎

很多 .NET 想做 SSG 的人，会优先用现成完整框架，而不是自己手写生成器：

• Statiq：.NET 最知名 SSG，底层就是 Scriban。完整框架，带路由、资源复制、增量构建、watch 热更新。
• Wyam（Statiq 前身）
• 还有 Simplify.Web 等

👉 也就是说：Scriban 大多是作为底层库被 Statiq 封装使用，很少有人直接裸写 Scriban 控制台程序自己搭建整套 SSG 流水线。 网上搜案例，搜到的都是 Statiq + Scriban，纯手写控制台 + Scriban 的工程案例非常少，所以你会感觉 “几乎没人这么干”。

3. Scriban 的定位：模板引擎，不是开箱即用 SSG

Jinja2 很多人直接写脚本拿来做 SSG，因为 Python 脚本一行就能读取文件、IO、数据处理。 Scriban 只负责渲染模板字符串。 剩下配套代码（目录创建、复制静态资源、增量构建、路由管理、json 导出、清理 dist 目录）全部要你自己手写 C# 代码。

别人用 Statiq，这些能力框架自带；你裸写 Scriban，所有周边脚手架代码自己写。 这就是案例少的最大原因：轮子要自己拼。

4. 人群割裂

• 量化数据看板爱好者：大多 Python 栈，直接 Python+Jinja2，不会跑到.NET 这边
• 普通 .NET 后端：做网站优先 Razor，不会想搞静态生成
• 前端：VitePress、Hugo，根本不碰 C#

所以交集很小：同时满足【C# 开发者 + 做数据看板 + 想自建 SSG】的人本来就很少。

二、小众带来的优缺点（客观看待）

✅ 好处

1. 对你：全链路 C#，采集、统计计算、定时任务、日志、异常重试都是你熟悉的工业级写法，不用跨语言。
2. Scriban 本身稳定，MIT 协议，成熟，生产项目可用；
3. 轻量可控，没有 Statiq 这种重型框架的学习负担，整个生成器就是一个简单控制台程序，想看懂全部源码。
4. 架构极简，没有魔法，每一步都是你写的代码，后续想改增量生成、自定义 json 输出逻辑，完全可控。

❌ 坏处

1. 网上现成完整案例少，踩坑只能靠自己调试；遇到问题，StackOverflow 上示例不多；
2. 脚手架代码（目录处理、资源同步、增量构建）需要自己维护；
3. 如果以后想找人协作，懂这套方案的人不多。

三、两个备选方案，给你参考（同.NET 生态）

方案 A：Statiq（底层 Scriban）

Statiq 是完整 SSG 框架，自带路由、静态资源、增量构建、watch 开发模式。

• 底层模板引擎就是 Scriban；
• 不用手写 dist 清理、文件复制； 缺点：有框架学习成本，它有自己的一套概念，对于你这种简单估值看板，有点 “杀鸡用牛刀”。

方案 B：Razor 模板引擎（不用 Scriban）

.NET 原生 Razor 模板，可以用 RazorLight 包，在控制台渲染 Razor 模板。 很多.NET 开发者如果要做离线 HTML 渲染，优先选 Razor，语法是熟悉的 @Model。

对比 Scriban：Razor 是 C# 风格模板；Scriban 语法接近 Jinja/Liquid。 如果你习惯 Razor 语法，RazorLight 也是不错替代。

四、回到你的项目：要不要继续坚持「裸写 C# + Scriban 控制台生成器」？

✅ 推荐继续，如果你满足下面两点：

1. 项目定位：个人估值看板，固定指数池，盘后一次性生成，不会大规模团队协作
2. 你希望完全掌控整个生成流水线，不想引入 Statiq 这种重型框架

你现在的场景本质：不是博客 / 文档站那种复杂 SSG，只是一个轻量数据导出 + 页面渲染工具。 你的生成器任务就三件事：

1. 读取算好的估值数据
2. 渲染少量页面模板（首页、几十条指数详情页、口径说明页）
3. 输出 HTML + JSON 数据文件，复制静态资源

工作量很小，Scriban 完全够用。虽然圈子里很少人这么搭，但对你的场景非常匹配。

类比：很多人用卡车拉货，但你只是想拉一小批货物，自己组装一台小型平板车，市面上同款平板车很少，但足够完成你的任务。不是错误方案，只是非主流。

备选折中方案

如果你不想从零手写全部脚手架，直接用 Statiq.Web，底层 Scriban，省去文件 IO、目录管理代码，专注写模板和数据加载逻辑。

五、一个现实对比：baifenwei 的 Python + Jinja2 vs 你的 C#+Scriban

表格