3.2 三大指令的分工与陷阱
3.2 三大指令的分工与陷阱
本节摘要：指令是写给编译期的话：page 指令声明页面的身份与运行参数，include 指令在翻译阶段把公共片段融进本页源码，taglib 指令把标签库引入页面命名空间。它们不参与运行时逻辑，却在编译那一刻固化了页面的编码、结构与能力边界。上一站清点了"写逻辑"的括号，本站清点"定规矩"的指令，重点排掉两个高发陷阱——静态包含不跟编译与编码声明缺位。
指令是写给编译期的话
指令的语法一眼可辨：<%@ 开头。这个 @ 就是它的身份证——凡是 @ 开头的行，都在翻译阶段被消化，产物是字节码里的配置事实，而不是运行时执行的语句。这带来一个根本性质：指令的影响在编译完成后不可更改，你无法在请求过程中动态修改它。
三大指令各管一摊，管辖范围画成图更直观。
图3-2 三大指令的管辖范围
page 指令：页面身份的五项核心声明
page 指令属性众多，老站维护里真正高频的就五个，用表盘清：
| 属性 | 管什么 | 老站典型问题 |
|---|---|---|
| contentType | 响应类型与输出编码 | 缺省时用平台默认编码，跨环境部署就乱码 |
| pageEncoding | 源文件读取编码 | 与实际文件编码不符时，中文注释先变成乱码 |
| import | 引入脚本里要用的类 | 少了声明直接编译报错，报错行指向使用处而非指令处 |
| session | 是否创建会话 | 默认开启；纯展示页关掉它能省会话内存 |
| errorPage 与 isErrorPage | 异常跳转与错误页身份 | 第 7 章错误页体系的地基，此处先混个脸熟 |
其中编码双属性值得多说一句。contentType 声明的是"我发给浏览器的字节按什么编码解释"，pageEncoding 声明的是"容器读源文件时按什么编码解码"。两者可以不同但通常一致；最怕的是都不写——容器按默认配置走，开发机与生产机的默认值一旦不同，同一份代码在两边一个正常一个乱码，排查时极耗心神。青梧书肆的整改清单里，给每个页面补齐编码声明是机械但值得的活儿。
静态包含：一次真实的不生效工单
include 指令做的是文本级粘贴：翻译器读到它，就把片段文件的原文原样插进当前页面的源码里，合并成一份再编译。被包含的片段不是独立页面，没有自己的生命周期，它的变量与主页面直接互通。页眉、页脚、版权声明这类纯静态件，正是它的主场。
便利背后埋着本章标题里的那个陷阱，照例走一遍真实案例。
背景：运营要求更新全站页脚的备案文案。页脚是公共片段，被两百多个页面用 include 指令引用。你改了片段文件、部署，随机抽查几个页面——页脚是新的。第二天运维反馈：一半页面还是旧页脚，且说不清是哪一半。
操作：复盘静态包含的机制：片段在翻译时被拷进各页面的产物里，之后两者再无关联。片段文件更新后，容器只会在"片段自身被请求"时重译片段（它恰好也能被独立访问），而引用它的主页面时间戳未变，不会重译。哪些页面更新了？恰好是部署后恰好被访问、触发容器顺带校验的那些——随机感由此而来。
结果：清空容器的工作产物目录，强制全站重译，页脚统一更新。
解读：静态包含的"一处修改处处生效"只在重编译之后成立，而重编译的触发权在时间戳手里。这就是它和下一节动态包含最本质的分野：指令版融合发生在过去（编译期），动作版包含发生在现在（请求期）。
变式：如果你的站点公共片段更新频繁，或者片段内容依赖请求上下文（比如按登录态变化的头部导航），静态包含根本不是合适的工具——应该换成动态包含，那是下一节的内容。判断口诀：内容固定的结构件用指令，随请求变化的活内容用动作。
taglib：一扇通往标签库的门
三大指令里最有远见的是 taglib。它在页面上声明"我要用某个标签库，前缀叫某名字"，翻译器据此把页面里带该前缀的标签映射到对应的处理类。今天看它只是三行声明：
<%@ taglib prefix="c" uri="jakarta.tags.core" %> <%-- 引入后，c 前缀的标签就能用了，例如循环输出书名 --%>
但它的意义远超三行文字：这是页面摆脱 Java 语句的第一条通路。第 5 章的 EL 与 JSTL 去脚本化改造、第 6 章的自定义标签车间，全部从这扇门进出。uri 指认库的身份，prefix 是页面内的本地绰号——同一个库在不同页面可以叫不同前缀，读老代码时别被五花八门的前缀迷惑，看 uri 才认得真身。
⚠️ 常见坑：读到老页面里
<%@ include %>与<jsp:include>混用时，别当成同一件事的两种拼法——前者编译期粘贴、后者运行期执行，行为差异大到能出事故。对照表在下一节。
指令的两条合并规则
多指令并存时，容器的合并规则值得一记。其一，page 指令可拆可重：同一页面里 page 指令出现多次完全合法，除一个属性例外——它只能在页面里出现一次，写两遍直接编译报错。这条例外让"include 进来的片段带了自己的 page 指令"变得微妙：静态包含会把片段原文融进主页面，若两边都声明了 contentType 且值不同，合并后的页面就是重复声明的违规现场。静态包含只用纯结构件、结构件不写 page 指令，这条纪律的出处就在这。其二，include 指令不受条件控制：它写在页面哪里、编译时就融合到哪里，不存在"运行时才决定包不包含"——想按条件包含，那是动作元素的活儿（下一站）。两条规则合起来的口诀：指令是编译期的化学键，一旦融合就分不出彼此，写之前先想清楚合并后的样子。
指令核查的批量做法
指令核查在单页上很简单，难在全站。青梧书肆的批量核查做法可以借鉴：先把全站指令按类型抽出来做成三张清单——page 指令清单看编码双声明与错误页指向的覆盖率，include 指令清单看被包含的片段是否真的"内容固定"，taglib 指令清单看 uri 是否有五花八门的写法。清单抽出来后，问题自己会浮出来：编码声明缺了四成页面、include 引用的片段里有三个其实带着请求逻辑、同一个标准库的 uri 出现了新旧两种写法。三张清单各自对应一批整改工单，指令核查从"逐页读代码的苦活"变成"对清单的快活"。这个做法的通用价值在于：语法元素的核查都可以先抽取、后归类、再批量整改——比一页页翻高效得多，也更容易向管理层汇报进度。
本节要点回顾
- 指令在编译期生效：@ 开头的行翻译时消化完毕，运行期不可变更；
- 编码双声明：contentType 管输出、pageEncoding 管读取，缺省会埋下跨环境乱码；
- 静态包含是文本粘贴：片段融入主页面源码一次编译，片段更新不自动唤醒主页面，需要强制重译；
- taglib 是扩展之门：uri 认库、prefix 起绰号，第 5、6 章的标签化改造从这里起步。
指令把页面的规矩定完了，剩下最后一类元素：以 jsp 为前缀的动作标签。它们能在运行期包含页面、转发请求、绑定对象——下一站清点这批"用标签写 Java"的过渡形态。