我上周做内部技术分享的时候又被PPT折磨了一次。讲的是前端性能优化结果自己先被Keynote的性能折腾得够呛改了一个标题字号整页版式跟着错位从编辑器里复制进来的代码块粘贴后高亮丢得一干二净演示时想放大一张截图动画卡成了逐帧播放。台下坐着的都是写代码的同事那一刻我差点直接把浏览器里的官网Demo当演讲稿。散会之后我认真想了想我本来就是做前端的为什么做演示稿的时候反而把自己最擅长的一整套工具链全扔了从那次开始我把对外分享用的Slides全部改成了前端方案。这里说的Frontend Slides不是某一个固定开源项目的名字而是用HTML、CSS、JavaScript以及围绕它们的前端框架去制作演示文稿的一套方法。它可以是一个手写的单页面也可以基于reveal.js、Slidev这类现成工具来做。这篇文章不打算只推荐某个“最好”的框架而是把前端Slides从原理、选型到实操的完整链路讲清楚核心代码为什么这么写、工具到底怎么选、演示现场会遇到什么幺蛾子、最后怎么部署成一个所有人打开链接就能看的在线稿件。如果你是前端从业者或者经常做技术分享哪怕完全没用过代码写Slides按这条路线走一遍也能上手。1. 先想清楚代码写Slides到底是在解决什么问题1.1 传统PPT最让人难受的四个场景很多人一提PPT就说“它够用了”这话没毛病日常汇报确实打开Keynote或者PowerPoint拖几下就行。但一旦你讲的领域偏技术问题就来了。第一个场景是代码展示。技术演讲里离不开代码片段直接从IDE复制进PPT字体缩进偶尔会乱高亮基本全丢你只能手动套一个“代码样式”的文本框行号、关键字颜色、注释颜色全部自己调。讲三页代码没问题讲三十页代码光调格式就够加班。第二个场景是版本管理。PPT本质是二进制文件公司里两个人同时改一个演示稿用网盘同步大概率互相覆盖。就算用Git管理二进制文件也没办法做正常的diff谁也说不清楚上一次“微调”到底改了哪一页。第三个场景是临时改动。演讲前两小时某位负责人跑来说“这里加一页、那里删一段”用PPT改会牵涉到版式、母版、动画序列。前端Slides里加一页就是加一段Markdown或一个组件干净利落。第四个场景是跨设备观看。现在很多分享不再是会议室里一群人看投影而是线上会议、直播、录屏PPT需要导出成PDF或者录屏视频。前端Slides天然就是网页分享一个链接观众在手机、平板上都能看不需要安装任何办公软件。1.2 前端Slides真正解决的和解决不了的把Slides当成一个前端项目以后很多传统痛点自然就没了代码高亮由Shiki或者Prism来处理所见即所得整个项目可以放进Git每次修改都能review构建产物是静态站部署以后随时更新链接观众打开永远是最新版样式用CSS控制字号、间距、主题色全部可复用。但我也得泼一点冷水。前端Slides不是万能药它解决不了“不会排版”的问题。PPT擅长的是可视化拖拽你随手放一张图、拖一个文本框、加个箭头就能出效果。前端方案里这些都要通过布局代码来完成。如果你只想做一份很随意的图文汇报又不想学CSS前端Slides的初期效率大概率比PPT低。另外像手写批注、现场圈画、白板演示这类场景PPT配合触控笔确实更方便。前端Slides并不是要取代PPT它更适合内容密度高、代码多、需要版本维护、需要以网页形式分发的场景。1.3 谁适合改用前端Slides我的判断标准很简单符合下面任一条就可以认真考虑前端方案分享内容里代码占比高需要高质量语法高亮比如框架原理、工程化、源码解析。你需要把同一套演示稿在不同场次反复讲每次只改数据和局部内容。你希望演示稿参与代码评审让同事通过Git提意见。你希望演讲结束后观众拿到一个能够继续交互的链接而不是一份静默的PDF。你所在团队本身就有前端工程化基础愿意为一次高质量分享多花一两个小时。反过来说如果这份演示稿是给客户看的花哨提案强调视觉冲击力或者你只有十分钟准备时间对技术细节无感那还是用回传统工具吧别和自己过不去。2. 核心原理一张Slide本质上就是一个视图2.1 先忘掉“页”的概念想成“路由”传统PPT的一页在浏览器里可以理解成一张独立的视图。前端Slides所有花活本质都是在管理“当前应该显示哪一块内容”的状态。我见过很多人第一次接触这类工具时以为Slides是某种魔法其实背后的模型非常简单每一个Slide就是一个DOM节点或者是React/Vue里的一个组件。前端框架根据当前页码决定渲染哪一个节点切换页码就是修改页码状态的更新过程。这和我们平时做页面路由非常像。浏览器路由分为hash路由和history路由Slides工具往往选择hash路由。原因很直接hash变化不会触发页面刷新而且刷新以后还能停留在当前页用户手动改地址栏里的#/3也能跳转到指定页。2.2 不用框架十几行代码也能跑通切换为了让你彻底放心可以先用原生HTML和JavaScript演示一下最核心的切换逻辑。假设页面上有这么几个Slide容器section classslide active第一页/section section classslide第二页/section section classslide第三页/section对应的JavaScript只需要监听hashchange事件把当前hash解析成页码再切换对应节点的类名function updateSlide() { const hash location.hash || #/0; const index parseInt(hash.replace(#/, ), 10) || 0; document.querySelectorAll(.slide).forEach((el, i) { el.classList.toggle(active, i index); }); } window.addEventListener(hashchange, updateSlide); updateSlide();CSS里把非当前页隐藏起来.slide { display: none; } .slide.active { display: block; }这样就已经具备了最基础的Slides能力浏览器前进后退可以切换页面刷新后停留在当前页。所有成熟工具做的无非是在这个基础上增加过渡动画、嵌套布局、演讲者备注、代码高亮、自动缩放等能力。2.3 一屏正好放一张Slide缩放适配怎么做前端Slides和普通网页一个显著区别是普通网页可以纵向滚动但Slide必须保证在某个固定尺寸下完整展示。通常设计稿尺寸是1920x1080或者1280x720。直接给每个Slide设置固定宽高听起来简单但观众屏幕大小不一投影分辨率也千差万别。常见做法是设定一个基准视口尺寸再动态计算缩放比例用CSS的transform: scale()把Slide整体缩放到正好填满可用区域。比如设计稿宽960、高540当前视口是1920x1080缩放比例就是Math.min(1920/960, 1080/540)取两个比例里的较小值可以避免溢出。窗口变化时监听resize事件重新计算一次。这就是很多Slides框架“自适应屏幕”的核心逻辑原理并不复杂。2.4 为什么不是所有网站都适合这套机制理解了这个原理你也会明白为什么前端Slides不适合用来做长文章。它的核心是“锁定视口”所有内容必须被塞进一屏。一旦某页内容太长只能在Slide内部滚动体验会非常割裂。搜索引擎也不喜欢这种隐藏内容的方式。所以前端Slides的定位应该是“演示场景下的应用”不是普通的文档站点。你可以在旁边附一个链接给观众看完整文章但不要把技术博客改写成Slides。这是两个完全不同的信息载体。3. 选型对比手写一套、reveal.js、Slidev该怎么挑3.1 手写方案的定位和边界自己手写Slides的优势是零依赖、完全可控。如果你只需要十几页每页内容就是标题加几句要点又不想引入构建工具那么原生HTML加几十行CSS就是一个很好的方案。我早期做过一个团队内部的黑客松分享整个项目只有一个index.html和一个style.css部署到Nginx就完事维护成本极低。但手写方案的上限也很明显代码高亮、演讲者备注、快捷键、打印导出、组件化这些能力都需要你自己造轮子。尤其当你需要把一页Slide拆成多个小组件复用或者加入复杂的代码展示效果手写成本会指数级上升。建议把“手写”当成理解原理和应付极简需求的备选方案而不是长期主战方案。3.2 reveal.js稳定成熟的老牌选择reveal.js从2011年前后就存在了生态非常稳定。它采用纯HTML结构一个section就是一张Slide支持Markdown语法但整体还是“HTML为中心”的使用方式。主题丰富插件多比如代码高亮、注释、拼图、自动播放等。用reveal.js做Slides适合喜欢自己掌控HTML结构的人。你可以把任意HTML、CSS、JS嵌进去自由度很大也因此比较容易写出“一次性”的页面代码。它的缺点是整体开发体验偏传统如果你已经习惯Vite、Webpack这一套现代前端工程化流程会觉得它在构建和组件化方面不够顺手。3.3 SlidevMarkdown驱动为开发者定制的现代方案Slidev是我目前最常用的方案。它是基于Vite和Vue 3构建的核心思路是“把内容写进Markdown把交互交给组件”。每一页Slide就是Markdown里用---分隔的一节头部可以用YAML配置主题、布局、字体等元信息。和reveal.js相比Slidev更贴近“写文档”的习惯。分享内容本身是纯文本方便Git diff代码高亮内置了Shiki支持常见的代码编辑器配色。演讲者视图、录屏模式、远程控制这些功能都内置了不需要额外拼插件。由于它底层是Vue应用你可以在Markdown里直接使用Vue组件甚至把复杂图表封装成组件按需引入。这个特性让它既能快速写内容又能应对复杂定制场景。3.4 选型对比一张表把决策讲清楚下面是我自己总结的对比表维度不一定全但覆盖了最常见的判断点维度手写reveal.jsSlidev上手成本最低较低中等代码维护体验差全靠自己一般HTML为主好Markdown为主代码高亮需手动引入插件支持内置Shiki主题定制自己写CSS主题丰富主题可配置可组件化组件化差较弱强Vue组件打印导出自实现有导出插件内置导出命令远程控制自实现有现成方案内置远程控制器适合场景极简演示HTML老手快速部署技术分享、文档化演示3.5 我的实际推荐遇到新项目你不需要在三个方案里纠结太久。我的习惯是如果这次分享内容很多、代码量不小就直接选Slidev如果公司内部已经有了一个可用的reveal.js模板要求快速修改我就在它上面改如果只是临时给组内讲十分钟连依赖都不想安装那我宁可用手写HTML也不去开一个重型工程。选型最重要的是匹配场景不是追求最新技术栈。框架本身不是生产力内容才是。4. 从零开始用Slidev做一份带代码高亮和演讲者备注的Slides4.1 环境准备与项目初始化我用Slidev举例因为它的上手路径最接近“正常前端项目”。你本机需要Node.js 18及以上版本然后打开终端执行npm create slidevlatest my-slides命令运行后它会问你是否安装依赖选择“是”。初始化完成后进入目录启动开发服务器cd my-slides npm run dev浏览器打开http://localhost:3030你就能看到一页默认的示例Slide。Slidev的开发模式改了Markdown或代码会热更新这一点和普通Vite项目完全一致改完立即刷新页面不用手动重启。4.2 第一份slides.md怎么写Slidev的核心文件是项目根目录下的slides.md。打开它你会看到类似下面的结构--- theme: seriph --- # 前端性能优化 今天聊三个方向 --- # 第二页 - 指标 - 工具 - 案例 --- # 第三页 一张图胜过千言万语每一页Slide用一行---分隔。文件最顶部的---包裹区域是YAML配置用于设置主题、布局、字体等元信息。Markdown里的#、-等语法最终会被渲染成网页内容。如果我想展示一段带语法高亮的代码只需要像写普通Markdown一样写代码块Slidev会自动用Shiki高亮--- # 代码页 --- javascript const sum (a, b) a b; console.log(sum(1, 2)); 你不需要手动指定高亮主题它默认会跟随当前代码编辑器的配色方案。这一点对技术分享真的太重要了省掉了大量粘贴代码后调整格式的琐碎工作。4.3 代码高亮、演讲者备注和快捷键在Slidev里演讲者备注写在每页Slide末尾的注释里--- # 第二页 --- - 指标 - 工具 - 案例 !-- 这里写演讲者备注观众不会看到 --进入演示模式后按键盘上的P键可以打开演讲者视图当前页、下一页、备注、计时器都会显示在同一屏上。如果你的外接显示器或者副屏放不下了可以把演讲者视图拖到另一块屏幕主屏幕继续放全屏Slides。我常用的快捷键有这些空格或右方向键下一页左方向键上一页P切换演讲者视图F切换全屏O打开总览模式方便跳页D切换深色模式这些快捷键不是花架子当你讲到一半被观众打断提问时用O快速跳回前面的某一页比连续按十几次左方向键体面得多。4.4 换主题和布局别让默认样式绑架你Slidev自带几个主题比如seriph、default、glass等。用主题只需要在YAML头部修改--- theme: default ---如果默认主题的标题颜色、正文字号、背景色不够用你还可以在项目根目录创建style/index.css通过CSS变量覆盖主题样式。比如想让标题字体更大.slidev-layout h1 { font-size: 2.5rem; }针对一些固定的布局需求Slidev提供了layout字段例如左右两栏布局--- layout: two-cols --- # 左栏内容 - 第一点 ::right:: # 右栏内容 - 第二点这种布局在对比方案、展示代码和截图时非常实用。你不需要自己写一行布局CSS只需要在正确的位置用::right::切分左右两栏。从建项目到写出第一份像样的分享稿熟练以后大概三十分钟以内就能完成。前几次可能慢一点因为你要熟悉布局语法和主题配置但一旦踩顺了效率真的比打开一个空白PPT再一点点排版高得多。5. 演示现场最常翻车的三个地方字体、动画和远程翻页5.1 字体加载带来的“演示机翻车”有一次分享前我把Slides部署好了临时换了台演示电脑一打开发现标题字体全变了中文变成了宋体英文变成了奇怪的无衬线体。原因很简单我在开发机上安装了某个商业字体但没有通过Web Font的方式引入也没有指定可靠的字体回退方案。前端Slides是跑在浏览器里的最终效果取决于那台机器的字体环境。如果依赖本机字体会导致不同设备表现不一致。跨设备演示前要么在项目里把字体打包成Web Font要么明确指定字体系列栈把系统中常见的字体放在回退列表里body { font-family: Inter, PingFang SC, Microsoft YaHei, sans-serif; }另外如果你要在无网环境下演示字体文件必须打进静态资源目录不能依赖在线字体服务。这个坑我踩过一次之后都会在演示前把网络断掉测一遍所有页面确保离网也完全可用。5.2 动画为解释服务不为炫技服务前端Slides最大的优势之一是可以写丝滑的CSS过渡、SVG动画甚至Canvas动画。但我也见过不少人把Slides做成了“交互动效演示”每页都有飞入飞出、旋转、缩放结果内容反而被动画淹没了。分享时听众的注意力很宝贵。动画应该用来解释“动态变化”比如性能指标升降、数据结构流转、组件生命周期而不是让标题从左向右飞进来。Slidev默认的过渡动画已经足够克制如果你要自定义页面切换建议统一方向和时长不要每页都换一个花式效果。实测下来动画时长控制在200到500毫秒之间最舒服太短像闪屏太长又拖节奏。5.3 远程翻页手机控制端没反应怎么办线下演示时把笔记本电脑放到演讲台人却站在屏幕前走来走去这时就需要远程翻页。Slidev内置了远程控制功能启动npm run dev或构建预览后浏览器地址栏会出现一个小图标点击后生成二维码手机扫描就能进入遥控页面。听起来很美好但实际演示时最容易翻车的是“手机和电脑不在同一个局域网”。很多公司Wi-Fi默认开启了AP隔离手机能连Wi-Fi但访问不到电脑上的服务。我现在的做法是手机开热点电脑连上同一个热点先测试一下能否访问网址再进入演示环节。这个操作看起来笨但能避免现场尴尬。另外遥控页只能触发翻页不能替代可靠的物理遥控器。如果条件允许我建议准备一根备用HDMI线或者直接用键盘翻页。远程控制是加分项不是唯一方案。5.4 备用方案导出PDF兜底再成熟的技术方案也架不住现场投影仪抽风、视频线接触不良、系统更新强制重启。所以我现在每次分享前都会用Slidev的导出功能生成一份PDF放在手机或平板上npx slidev export这个命令会启动无头浏览器把每一页Slides截图排版成PDF。PDF不存在字体缺失、浏览器兼容性问题任何设备都能打开。就算现场电脑彻底废了我也能掏出平板照着PDF讲至少不会让观众干坐着。PDF不是用来替代网页版而是作为兜底。如果你讲的内容里有大量动态演示PDF可能没法覆盖可以在对应页放一张截图或者二维码引导观众现场打开互动Demo。6. 构建与部署把演讲链接发给与会者6.1 构建静态站点的标准流程前端Slides的最终交付形态应该是一个静态网站目录。Slidev的构建命令很简单npm run build构建完成以后项目里会多出一个dist目录里面是纯静态的HTML、CSS、JS资源。把这个目录扔到任意静态服务器上就能运行不需要Node环境。需要注意如果你要部署到GitHub Pages这种带子路径的地址比如https://yourname.github.io/my-slides/必须给项目配置正确的base路径。常见做法是在项目根目录创建vite.config.tsexport default defineConfig({ base: /my-slides/, plugins: [vue()] })如果不配置base构建出的资源路径可能从根目录开始找部署上线后会出现样式丢失、页面白屏的情况。这个坑是静态部署里的经典问题几乎每个人都会遇到一次。6.2 部署和更新给观众一个“永远能打开”的链接静态站点可以部署到各种平台比如GitHub Pages、Netlify、Vercel、对象存储加CDN甚至你内部的一台Nginx服务器。我的习惯是内部技术分享放到内网静态服务器外部分享部署到线上托管平台并开启自动部署。每次改完内容提交GitCI自动跑构建和发布观众拿到手的一直是最新版本。还有一点值得注意如果你不想让Slides被搜索引擎收录或者不想让人随意修改可以部署后用访问控制插件限制权限。但大多数技术分享场景下公开部署反而更好观众会后能从链接里看到你的代码示例和引用资料比发一份只会让人“只读”的PDF更容易传播。6.3 导出PDF的格式问题用npx slidev export导出PDF时有几个小问题容易忽略。一是动画状态如果一个元素默认是隐藏的导出后可能不会显示你需要确保关键内容在静态状态下完整可见。二是中文和特殊字符如果代码或图表里包含emoji和特殊符号要检查PDF里是否被无头浏览器正确渲染。三是尺寸默认导出是宽屏16:9但如果你某几页用了从右到左的滚动布局导出后可能错位。我的习惯是导出后快速翻一遍PDF缩略图重点看含有代码高亮、图表和上下标的部分。别信“代码生成的一定没问题”构建环节总会带来一些意外。7. 进阶把Slides当成一套组件库来维护7.1 把复用内容拆成组件当你做技术分享的频率上来以后会发现自己总在重复做类似的东西标题页、目录页、要点页、代码对比页、数据指标卡。Slidev里可以用Vue组件把这些“高频页面骨架”抽象出来。在Slidev项目的components目录下新建一个MetricCard.vue写一个简单的组件来展示指标名称和数值template div classmetric-card span classmetric-name{{ name }}/span span classmetric-value{{ value }}/span /div /template script setup defineProps({ name: String, value: String }) /script然后在Markdown里直接引入MetricCard nameFCP value1.2s /这样后续分享里要改指标的时候只需要改数值不需要在每个Slide上重新排版。分享稿变成了“数据配置 少量排版描述”维护成本降了一个量级。这就是把Slides当工程做和当文档做的本质区别。7.2 沉淀自己的主题样式除了组件你还可以把自己的品牌色、标题风格、代码块配色沉淀成一个主题包或者至少写一份全局CSS。团队内部做分享时所有页面风格统一看起来就非常专业。这个统一感不是靠一页页调出来的而是靠CSS变量和全局样式控制。比如在style/index.css里定义主题颜色:root { --primary: #2563eb; --text: #1f2937; --code-bg: #f3f4f6; }然后在组件或Markdown引用的类中使用这些变量。以后想换主色调只需要改一处整份Slides跟着变。这个思路和设计系统的Token机制是一样的只不过你服务的对象是演示内容。7.3 可访问性容易被忽略但很重要的细节前端Slides做出来以后不只是演讲现场有人看。会后发出去的链接可能有观众在手机上刷、有人用屏幕阅读器听、有人因为配色不当看不清。所以可访问性要放在上线前检查一遍。最基本的三件事文字对比度要足够深色背景上不要放浅灰色小字。所有图片和图表要有替代文字方便屏幕阅读器描述。键盘可以完整操作Tab键能聚焦到交互控件而不是只有点击才能翻页。很多Slides框架默认把页面定位成“演讲屏幕”可访问性细节需要自己补。比如给每一页加语义化标题、给链接加上说明文字、给状态变化提供提示。这些工作看起来琐碎但在线上传播场景里它决定了一部分人能不能真正看懂你的内容。我自己每次分享完都会把部署链接发到团队群里让没去现场的同事也能自己打开看。前端Slides带来的这种“可分发、可维护、可变”的体验已经让我很少回头再打开传统PPT了。如果你也想试试别急着研究花哨的主题和动画先把第一份slides.md跑起来比什么学习路径都管用。