用ssr工具

去年冬天，工具我在一台旧笔记本上跑一个前端项目，工具热更新慢得能泡完一杯茶。工具同事扔过来一句：“你试试 ssr 工具，工具别死磕 webpack 了。工具”我当时以为他说的工具是服务端渲染，后来才搞明白，工具他指的工具是 ssr 这个命令行工具——一个用于快速启动本地开发服务器的轻量方案。名字确实容易混淆，工具但用起来完全是工具另一回事。

安装很简单，工具一行 npm i -g ssr 就完事。工具真正让我意外的工具是它的启动速度。同样一个静态站点目录，工具ssr 几乎是工具在按下回车后的半秒内就吐出了本地地址。没有配置文件，没有插件系统，没有那一长串 webpack 的进度条。它做的事情很单一：把当前目录当成网站根目录，起一个 HTTP 服务，支持 HTML/CSS/JS 的即时刷新。就这么点功能，但恰好覆盖了我日常调试的八成场景。

我拿它试过一个纯静态的文档站，大概三百多个 HTML 文件。用 ssr 启动后，浏览器里点链接、改样式、刷新，响应几乎是瞬时的。它内置的 livereload 不是通过注入一大坨脚本实现的，而是利用 WebSocket 发一个极简的 reload 信号。我抓包看过，消息体只有几个字节。这种“够用就停”的设计思路，在如今动辄几百兆依赖的前端工具链里，反而显得稀罕。

当然，它不能替代完整的构建工具。如果你需要 TypeScript 编译、Sass 预处理、模块打包，ssr 帮不上忙。我的做法是：日常写页面结构和样式时用 ssr 快速预览，等到需要打包发布时再切回项目里配好的 vite 或 webpack。两个工具各管一段，互不打架。这比硬把所有功能塞进一个工具里要舒服得多。

有个细节值得提：ssr 默认监听 8080 端口，如果被占用会自动往后找。我有次同时开了三个项目，它分别占了 8080、8081、8082，终端里直接打印出三个地址，一目了然。这种小地方的顺手，比很多所谓“智能”工具强。另外它支持 --port 和 --host 参数，想暴露到局域网给手机测试也很方便。我试过在手机上打开同一 WiFi 下的地址，页面加载正常，livereload 也能触发。

不过它有个坑：不支持 history 模式的路由回退。如果你的单页应用用了 vue-router 的 history 模式，直接访问 /about 会 404。解决办法要么改用 hash 模式，要么在 ssr 前面挂一个简单的代理规则。我后来写了个三行的 express 中间件套在前面，才算把这个问题绕过去。工具本身没提供这个功能，文档里也没写，算是一个需要自己补的缺口。

我现在的习惯是：新起一个纯静态页面或者写 demo 时，第一件事就是 cd 到目录然后 ssr。它不试图解决所有问题，也不强迫你学习一套新的配置语法。你只需要知道它会把当前目录变成网站，然后改文件、看效果。这种直接了当的反馈循环，在调试 CSS 布局或者写小工具页面时，比任何花哨的功能都管用。

如果你手头也有那种“只想快速看个页面效果”的场景，不妨装一个试试。它不会让你惊艳，但大概率会让你少等几次编译。工具这东西，有时候简单比强大更难得。