JSP自定义标签开发：SimpleTagSupport与TagSupport的区别

基础定位与版本背景 #

• TagSupport 是JSP 1.2规范时代推出的经典标签API配套基类，是对早期Tag、IterationTag接口的通用默认实现，目的是减少早期自定义标签开发需要实现的空接口方法，适配当时JSP容器的标签生命周期设计
• SimpleTagSupport 是JSP 2.0规范新增的简化标签API配套基类，专门解决经典标签API设计繁琐、状态维护成本高的问题，是当前新开发自定义标签的优先选择

核心实现差异点 #

生命周期逻辑复杂度 #

• TagSupport 采用多阶段拆分的回调流程：标签初始化时触发doStartTag()、需要循环处理标签体时触发doAfterBody()、标签渲染结束时触发doEndTag()、容器回收标签实例时触发release()。每个方法的返回值需要手动匹配规范常量（比如EVAL_BODY_INCLUDE、SKIP_BODY、EVAL_PAGE），返回值写错极易引发流程错乱
• SimpleTagSupport 采用单入口的简化流程：所有标签逻辑都可以在唯一的核心方法doTag()中完成，不需要拆分多阶段回调，也不需要记忆大量流程控制常量，开发心智负担极低

标签体处理能力 #

• 基础的TagSupport实现默认无法拦截、修改标签体的渲染内容：如果需要操作标签体，必须额外实现BodyTag接口，搭配BodyContent对象才能拿到标签体的输出流，开发步骤繁琐
• SimpleTagSupport 原生支持任意标签体操作：在doTag()方法中可以直接通过getJspBody()获取代表标签体的JspFragment对象——如果要跳过标签体执行，直接不调用invoke()方法即可；如果要修改标签体内容，可以先把invoke()的输出写到自定义的StringWriter中，处理完再渲染到页面，不需要额外实现其他接口

实例缓存与线程安全特性 #

• TagSupport 的实例会被JSP容器缓存复用：同一个标签的实例会跨请求多次处理不同用户的请求，如果开发时把请求级的变量存在类的成员变量中，很容易引发并发场景下的线程安全问题，必须手动在release()方法中清空所有成员状态
• SimpleTagSupport 的实例是每次调用时新建的：容器不会缓存复用其实例，每个用户请求、每个页面上的标签位置调用都会生成独立的对象，开发时不需要担心成员变量的线程安全问题，也不需要手动实现状态清理逻辑

开发选型建议 #

选型提示：如果是维护JSP 1.x时代的遗留老项目，只需要保持原有TagSupport的实现风格即可；新功能开发的自定义标签，优先选择继承SimpleTagSupport实现，代码量相比经典标签实现可减少60%以上，长期维护成本更低。

内容的提问来源于stack exchange，提问作者FarshiD Naqizadeh