用 HTML 做演示文稿：零依赖、视口优先、视觉引导先行

我有一段时间特别排斥用传统演示软件做分享——不是因为工具不好用，而是那些模板太容易让人滑进「通用美学」的陷阱：渐变背景、Inter 字体、白底黑字，一眼看过去和其他人的 PPT 毫无区别。后来我开始用纯 HTML 写幻灯片，意外发现这个方式逼出了一些值得记录的工程习惯。

零依赖是一个设计决策，不是洁癖

「一个 HTML 文件打天下」听起来像极客炫技，但它背后有真实的工程理由。

演示文件要能在任何浏览器本地打开，不依赖 Node 环境、不需要 npm install、不会因为某个 CDN 挂掉而白屏。把 CSS 和 JS 内联进 HTML，看起来违反了「关注点分离」的原则，但这里的「关注点」是演示本身的完整性——分离反而引入了额外的运行时依赖。

同理，字体可以从 Google Fonts 或 Fontshare 加载，但如果你在没有网络的会场打开文件，加载失败只是回退到系统字体，不会让整个演示崩溃。把关键字体 base64 内联进 CSS 是更保险的选择。

这个思路可以推广到更多场景：交付物的自包含程度决定了它的健壮性。 一份演示文稿如此，一个导出的报告如此，一段要在别人机器上跑的脚本同样如此。

视口是硬约束，不是软目标

做 HTML 幻灯片最容易踩的坑，是把每一页当网页在写——内容放不下就让它滚动。这在普通页面完全合理，但在演示场景里是灾难：听众看到的是一个被截断的画面，或者主讲人在台上疯狂滚动屏幕。

我给自己立了一条规则：每张幻灯片必须用 height: 100vh; overflow: hidden，内容放不下就拆成两页，绝不缩小字号到不可读的地步来「塞进去」。

这条规则的好处是逼着你重新考虑信息密度。一页能放多少内容是有上限的，一旦你接受这个上限，你就会开始主动删内容，而不是想办法塞进更多。约束是内容密度的自动节制器。

配合 clamp() 做流体排版——让字号和间距在不同屏幕尺寸之间平滑缩放，而不是写死像素值——基本上可以覆盖从手机横屏到 4K 投影仪的绝大多数场景。

视觉引导比风格问卷有效十倍

「你希望这个演示是什么风格？」是一个糟糕的问题。多数人不知道怎么回答，要么说「大气一点」，要么说「简洁一点」，这两个答案对设计方向毫无帮助。

我后来改成另一种流程：先问「你希望听众看完这个演示之后有什么感受？」——兴奋、专注、信任、受到启发？然后直接生成 3 个风格完全不同的单页预览让对方选，或者从中挑几个元素混搭。

视觉样本比语言描述高效得多。人们知道自己喜欢什么，但不一定知道怎么用语言表达；给他们看东西，他们会很快告诉你「要这个，但背景换成深色」。这个「展示而非询问」的原则不止适用于演示设计，在任何需要对齐审美或风格偏好的场景里都管用。

一句话心法

演示文件是一次性交付物，它的健壮性比它的架构优雅更重要；视口是你唯一的画布，接受它的约束，内容会因此变得更精炼。