shtml和html的区别

打开一个 .shtml 文件，用浏览器看，和 .html 几乎没差别。但服务器那头，处理方式完全是两码事。我第一次碰到 shtml 是在一个老论坛的源码里，当时以为是谁打错了扩展名。后来才知道，这玩意儿叫“服务器端包含”——Server Side Includes，缩写 SSI。

html 是纯静态的。浏览器请求一个 index.html，服务器直接把文件扔回去，内容原封不动。shtml 不一样。服务器收到请求后，会先扫一遍文件里有没有 <!--#include --> 这类指令。有的话，把指定文件的内容嵌进去，或者执行一些简单的命令，再把拼好的结果发给浏览器。换句话说，html 是端上桌的菜，shtml 是后厨还颠了两下勺才端出来的。

举个实际场景。一个网站有 50 个页面，每个页面顶部都有同样的导航栏。用 html 的话，改一次导航，得把 50 个文件全改一遍。用 shtml，把导航写进 nav.html，每个页面里加一行 <!--#include virtual="nav.html" -->。以后改导航，只动一个文件，所有页面自动更新。这就是 shtml 存在的最大理由——在静态页面里实现局部复用。

但这事有个前提：服务器得支持 SSI。Apache 默认不开启，需要在配置里加 Options +Includes，还得告诉它哪些扩展名要处理，比如 AddOutputFilter INCLUDES .shtml。Nginx 更麻烦，默认根本不认 shtml，得手动配 ssi on; 并且指定 ssi_types text/shtml;。我见过不少人把文件改成 .shtml 后发现 include 没生效，九成是服务器没配好。

性能上，shtml 比 html 多了一步解析和拼接。访问量小的时候感觉不出来，几千 QPS 以上，CPU 会多喘几口气。不过现在大家用 CDN 缓存，shtml 解析一次后结果就被缓存了，实际压力反而比纯静态小——因为你可以用更少的文件维护更多页面。

那为什么现在很少见到 shtml 了？两个原因。一是后端模板引擎普及了，PHP、JSP、Node 的 EJS 都能干同样的事，而且更灵活。二是前端构建工具起来了，Webpack、Vite 在打包阶段就把公共部分拼好了，根本不需要服务器运行时再做。shtml 像是上个时代的产物，但它在一些老站点、文档系统里还活着。比如 Apache 自己的文档，不少页面就是 .shtml。

还有一个容易混淆的点：.shtm 和 .shtml 是一回事，只是扩展名长短不同，服务器配置里通常两个都认。另外，shtml 文件里也可以写纯 HTML，没有任何 include 指令时，它和 html 表现完全一致。所以你可以把 .html 直接改名成 .shtml，只要服务器配置正确，页面照常显示。

要不要用 shtml？看场景。如果你维护一个纯静态站点，又不想引入构建工具，服务器恰好是 Apache 或 Nginx，那 shtml 能省不少复制粘贴的力气。但如果你已经在用 React、Vue 或者任何后端框架，shtml 就多余了。它是个简单工具，解决的是“静态页面里想复用一小块内容”的问题，仅此而已。

最后提一句：shtml 的 include 指令可以嵌套，但别嵌太深。我见过一个页面 include 了五个文件，每个文件又 include 了三个，最后服务器解析花了 200 多毫秒。这种时候，要么上缓存，要么换方案。工具是死的，怎么用看人。