9.1 同一个页面交给现代模板引擎
9.1 同一个页面交给现代模板引擎
本节摘要：把青梧书肆的图书详情页分别用 JSP 与现代模板引擎写一遍，差距就从抽象概念变成了具体行数：自然模板让模板文件本身就是合法页面、默认转义把脚本注入防护做成内建、与主流框架的装配更省事，代价则是部署形态与工具链的迁移成本。本节是选型评审的第一件证物——先看差距，再谈立场。
同一个页面，两种写法
评审要有证物。选图书详情页——页面足够典型：有取值、有条件、有列表渲染。JSP 版本你已经很熟了：
<h1>${requestScope.book.title}</h1> <p class="intro">${requestScope.book.intro}</p> <c:choose> <c:when test="${requestScope.book.stock gt 0}"> <span class="in-stock">现货，库存 ${requestScope.book.stock} 件</span> </c:when> <c:otherwise><span class="sold-out">暂时售罄</span></c:otherwise> </c:choose> <c:forEach items="${requestScope.comments}" var="c"> <div class="comment">${c.author}：<c:out value="${c.body}"/></div> </c:forEach>
同一段逻辑交给现代模板引擎（以主流的自然模板风格为例）：
<h1 th:text="${book.title}">图书标题占位</h1> <p class="intro" th:text="${book.intro}">简介占位文字</p> <span class="in-stock" th:if="${book.stock > 0}" th:text="'现货，库存 ' + ${book.stock} + ' 件'">现货</span> <span class="sold-out" th:unless="${book.stock > 0}">暂时售罄</span> <div class="comment" th:each="c : ${comments}"> <span th:text="${c.author}">读者名</span>： <span th:text="${c.body}">评论内容（默认转义）</span> </div>
两版并排，差异自己会说话。逐块对照画成图：
图9-1 同一页面的双栏对照
差距就在这几行里
三处差距值得放大。第一处是自然模板：现代引擎的动态指令挂在原生 HTML 属性上，模板文件本身是合法页面——前端同学双击就能在浏览器里看到接近成品的版式，改样式不需要启动任何服务端环境。JSP 版做不到：离开容器，c:forEach 里那半截页面根本无法预览。这条差距在"前后端两个人协作"的场景里值钱得很。
第二处是安全内建。JSP 版里那个 c:out 是我们反复强调的纪律，但纪律靠人守，漏一处就是 7.1 节的教训。现代引擎默认转义所有输出，想不转义反而要显式声明——安全从"约定"变成了"出厂设置"。以你刚补完安全课的视角看，这一条的心理分量不轻。
第三处是装配方式。现代引擎与主流框架的集成是声明式的：几行配置，控制器返回视图名即完成衔接。JSP 虽然也能接（第 4 章的骨架换个视图解析器就能跑），但要补齐容器的页面编译组件，且在新的打包形态下限制更多——可执行包里页面无法按传统方式定位编译，得退回传统的包形态部署。这引出了代价的一面。
代价与边界
迁移的代价要摆足。全站重写的工程量是最直的一笔账：几百个页面逐页改写、逐页回归，这还只是视图层；配套的自定义标签（第 6 章车间产物）要找对应替代或重铸。部署形态的约束紧随其后：团队若已决定走向新的轻量部署形态，JSP 的编译模型会持续别扭——反过来，若站点继续走传统容器部署，这条代价自动消失。学习与工具链成本排第三：模板语法、调试方式、错误提示都要重新建立肌肉记忆。
案例走一遍评审会上的实测环节。
背景：评审会分成了"守 JSP"与"换模板"两派，谁也说服不了谁。你提议：拿详情页做一天的概念验证，用事实代替立场。
操作：上午搭现代引擎的集成环境、写完对照版本；下午做三件事——前端同事独立修改页面并预览（协作测试）、故意注入一段脚本验证默认转义（安全测试）、检查部署脚本在两种打包形态下的兼容性（运维测试）。
结果：协作与安全两项，现代引擎优势实锤；部署一项，当前传统部署形态下双方无差异，但路线图一旦走向轻量化部署，天平立刻倾斜。
解读：这次实测的最大收获不是"谁赢了"，而是把抽象的选型讨论拆成了可测的判据。评审会上每个观点都应该能翻译成一个下午能验证的实验——做不到的，多半是立场而非观点。
变式：如果团队只有你一个 Java 工程师、没有前端协作诉求，自然模板的核心优势就折半了；反之如果前端团队即将进场，协作边界的价值会急速放大。同一条差距，对不同团队的定价完全不同——这正是下一站把"场景"引进选型的原因。
💡 关键直觉：模板技术的演进史，本质是一部"把正确的事变成默认值"的历史——转义从纪律变默认，预览从奢望变本能。看懂这条脉络，你对任何新工具的宣传都能自己定价：它把什么变成了默认？这个默认对我的团队值多少？
重写时的翻译对照清单
若决定动手重写，一份翻译对照清单能省一半工时。取值：脚本表达式与 EL 一比一换成新引擎的取值语法，作用域前缀的语义要对齐（按窄到宽就近查找的规则两边一致）。条件与循环：c:if 对应条件属性、c:forEach 对应循环属性，varStatus 的下标计数在新引擎里同样有对应物，奇偶行这类样式逻辑可原样翻译。转义：JSP 里显式的转义标签在新引擎里是默认行为，删掉即可；但注意"有意不转义"的地方（富文本片段）必须显式声明不转义，否则富文本会被转成一坨字符实体。包含：静态包含对应模板引用机制，动态包含对应片段渲染，参数传递从 param 改为新引擎的上下文传参。最后一条留给自定义标签：车间的三组标签在新栈里要么重铸为组件、要么继续由旧页面承担——按模块迁移的节奏走，别抢跑。清单贴在工位上，重写就是体力活；没有清单，每一页都是新决策。
概念验证的固化产出
那天的实测除了结论，还有一份容易被忽视的产出：概念验证代码本身。它值钱在三处。其一，它是后续任何重写预算估算的实物依据——评审者对着真实代码估工时，比对着幻灯片可信十倍。其二，它是新栈样式规范的雏形——验证页里怎么组织模板片段、怎么命名、怎么处理转义，直接抄进团队的模板规范，后来者有样学样。其三，它是分歧的纪念物——下次再有人为选型争论，把两版代码并排往桌上一放，讨论立刻回到事实层面。建议把概念验证单独存档（不混进主干），随评审纪要一起归档。维护期的许多决策不缺结论，缺的是可复查的证据链；概念验证固化为产出，证据链就算建立了第一环。
本节要点回顾
- 差距不在结果在过程：两版渲染可以完全一致，差别在协作边界、安全默认值与工具链；
- 自然模板值钱在协作：模板即合法页面，前端可独立修改与预览，双团队场景溢价最高；
- 默认转义消纪律债：安全从人守的约定变成出厂设置，是维护期最实在的减负；
- 代价三笔账：全站重写、部署形态约束、工具链重建，按站点实际逐一定价；
- 观点要能翻译成实验：一天的概念验证胜过十轮立场之争。
证物看完，评审进入第二项议程：替代技术盘点与迁移路线。重点研究那条"边跑边换引擎"的绞杀者路径。