clojure 的协议（protocol）天生是开放的，不支持 java 式的“密封接口”机制；但可通过词法作用域、私有协议与封装工厂函数，实现逻辑上的类型白名单控制，达成受控的 ad-hoc 多态。
clojure 的协议（protocol）天生是开放的，不支持 java 式的“密封接口”机制；但可通过词法作用域、私有协议与封装工厂函数，实现逻辑上的类型白名单控制，达成受控的 ad-hoc 多态。
Clojure 的协议设计哲学强调开放扩展性——它专为解决“表达问题（Expression Problem）”而生，允许任意命名空间中任意类型（包括第三方类型）在运行时动态扩展协议实现。这与 Java 中通过 sealed 关键字或模块化约束限制实现类的静态封闭机制存在根本差异。因此，Clojure 语言层面不提供、也不鼓励“密封协议”（sealed protocol）语法，如 :allows [...] 这类声明式白名单在 defprotocol 中并不存在，且 REPL 不会据此发出编译期或加载期警告。
但这并不意味着无法实现受控的 ad-hoc 多态。关键在于转换思路：放弃“强制语言级封禁”，转而采用封装 + 作用域隔离 + 构造约束的设计模式。其核心策略是：
- 将协议定义为 private（使用 ^:private 或置于 defn-/defprotocol 的私有命名空间内），防止外部直接 extend-type；
- 提供一组受信的、预定义的记录（defrecord）或类型构造函数；
- 所有协议方法仅通过封装后的工厂函数暴露，确保仅允许的类型被创建和使用。
以下是一个典型实现示例：
(ns mylib.core
(:require [clojure.spec.alpha :as s]))
;; 私有协议 —— 外部不可 extend-type
(defprotocol ^:private Shape
(area [this])
(perimeter [this]))
;; 预定义且唯一允许的实现类型
(defrecord Circle [radius]
Shape
(area [_] (* Math/PI radius radius))
(perimeter [_] (* 2 Math/PI radius)))
(defrecord Rectangle [width height]
Shape
(area [_] (* width height))
(perimeter [_] (* 2 (+ width height))))
;; 封装的构造函数 —— 唯一合法入口
(defn circle [r] (->Circle r))
(defn rectangle [w h] (->Rectangle w h))
;; 可选：用 spec 约束输入与返回类型
(s/def ::shape (s/or :circle #?(:clj Circle :cljs object?)
:rectangle #?(:clj Rectangle :cljs object?)))
在此模式下：
- 外部代码无法调用 (extend-type String Shape ...)，因为 Shape 协议未公开；
- 即使尝试 extend-type，也会因协议私有而失败（Clojure 1.12+ 在非定义命名空间中 extend-type 私有协议将抛出 IllegalArgumentException）；
- 所有合法实例必须经由 circle 或 rectangle 创建，天然形成类型白名单；
- 若需新增类型，必须修改 mylib.core 源码并重新发布，实现了语义上的密封性（sealing by convention & encapsulation）。
⚠️ 注意事项：
- 此方案无法阻止反射或低层 hack（如 alter-meta! 或 ns-interns 操作），但符合 Clojure 的信任边界模型：封装即契约，而非强制锁；
- 不适用于需跨库动态扩展的场景（此时应拥抱协议的开放性）；
- 若需更强约束，可结合 clojure.spec 对函数输入/输出做运行时校验，或在构建阶段集成 clojure.tools.analyzer 实现自定义 lint 规则。
总结而言，Clojure 不提供语法级密封协议，因其违背“动态组合优于静态约束”的设计信条；但通过私有化、封装与约定，开发者完全可以在应用层实现等效的受控多态——这不是缺陷，而是对语言动态性与工程可控性之间务实权衡的体现。
