在现代 web 应用中，特别是多租户环境中，实现细粒度的访问控制至关重要。传统的中央认证机制往往引入单点故障和性能瓶颈，而 Cap'n Web 作为一种 JavaScript/TypeScript 原生的 RPC 系统，通过对象能力（object-capability）模型，提供了一种去中心化的安全方案。该模型允许开发者在运行时动态委托和撤销能力，从而实现无需中央认证器的细粒度权限管理。Cap'n Web 灵感来源于 Cap'n Proto，但专为 web 栈优化，支持 HTTP、WebSocket 和 postMessage 等传输方式，整个库压缩后小于 10kB，无外部依赖。根据官方文档，“Cap'n Web supports capability-based security patterns”，这使得它特别适合构建安全的分布式应用，如多租户 SaaS 平台或实时协作工具。
对象能力模型的核心在于，每个对象（能力）仅能通过引用访问，且引用本身即是能力。这种设计确保了最小权限原则：能力只能被明确委托，无法意外泄露。在 Cap'n Web 中，能力委托通过 RpcTarget 类实现。当一个类扩展 RpcTarget 时，其实例在 RPC 传输中被视为引用（pass-by-reference），接收方获得一个 RpcStub 代理对象。RpcStub 使用 JavaScript Proxy 实现，允许远程调用方法或访问属性，而无需序列化整个对象。这实现了动态委托：例如，在一个多租户文件共享应用中，用户 A 可以将文件访问能力的 RpcTarget 实例传递给用户 B 的客户端。B 接收到 stub 后，即可调用如 read() 或 write() 方法，这些调用会通过 RPC 回传到 A 的服务器端执行。
委托过程无需预定义 schema，一切基于运行时类型推断，支持 TypeScript 的完整类型检查。考虑一个实际场景：服务器端定义一个 FileAccess 类扩展 RpcTarget：
import { RpcTarget } from "capnweb";
class FileAccess extends RpcTarget {
constructor(private filePath: string) {
super();
}
async read(): Promise<string> {
return "文件内容";
}
async write(content: string): Promise<void> {
}
}
在 RPC 会话中，服务器返回 new FileAccess("/user/file.txt") 作为响应。客户端接收到 RpcStub，可以直接 await stub.read()。这种委托是动态的：能力可以根据上下文条件授予，例如仅在用户会话有效期内传递 stub。更重要的是，支持双向调用和承诺管道化（Promise Pipelining），允许在单次网络往返中委托多级能力。例如，认证后立即管道化委托子能力，进一步减少延迟。在多租户环境中，这避免了中央 auth 服务的所有请求，提升了可扩展性。
然而，委托能力的同时，必须考虑撤销机制，以防止滥用。Cap'n Web 的撤销主要通过资源管理和处置（disposal）实现。每个 RpcStub 实现了 [Symbol.dispose] 方法，调用它会通知远程端释放关联资源。文档强调，“Explicitly dispose stubs when you are done with them. This notifies the remote end that it can release the associated resources。”这确保了能力在不再需要时被即时撤销，避免内存泄漏或持久访问。
处置支持显式和隐式方式。使用 JavaScript 的 using 语句，可以自动处置：
using stub: RpcStub<FileAccess> = await api.grantAccess(userId);
try {
await stub.read();
} finally {
}
对于需要持久引用的场景，使用 stub.dup() 创建副本，只有所有副本处置后，远程对象才被释放。这允许细粒度控制：例如，委托一个临时读能力，dup 一个审计副本。RpcTarget 可以实现自己的 dispose 方法，监听撤销事件：
class FileAccess extends RpcTarget {
[Symbol.dispose]() {
console.log("Access revoked");
}
}
在多租户应用中，撤销还需处理并发：如果多个租户共享能力树，处置一个 stub 不会影响其他，但需确保引用计数正确。Cap'n Web 的自动处置规则规定，调用者负责处置参数和返回的 stubs，系统在调用完成时隐式处置远程副本。这简化了管理，但要求开发者注意所有权转移。
为了工程化落地动态委托和撤销，需要定义可操作的参数和清单。首先，连接管理参数：对于 WebSocket 会话，设置心跳间隔为 30 秒，超时阈值为 60 秒；HTTP 批处理中，限制批次大小为 100 个调用，避免 pipelining 滥用。其次，处置策略：实现全局钩子监控未处置 stubs，使用 FinalizationRegistry 作为后备（尽管文档警告不可靠）。对于撤销，设置 TTL（Time-To-Live）为能力：如文件访问能力默认 1 小时后自动处置。监控要点包括：跟踪活跃 stubs 数量（警戒线 1000/租户）、处置失败率（<1%）、RPC 错误日志中检查 broken 事件（使用 stub.onRpcBroken()）。
回滚策略：如果撤销失败，重试 3 次后隔离租户；集成速率限制，如每分钟 50 个委托请求。清单：
-
初始化：验证 RpcTarget 继承。
-
委托：使用类型安全的 RpcPromise 管道化。
-
撤销：始终 using 或显式 dispose；dup 仅必要时。
-
测试：模拟并发委托/撤销，检查资源使用。
-
部署：Cloudflare Workers 中，利用内置 RPC 互操作性。
通过这些实践，Cap'n Web 使多租户应用实现零信任安全：能力仅在需要时存在，并可精确撤销。相比传统 JWT 或 OAuth，这种模型减少了状态管理开销，支持分布式场景。未来，可扩展到 WebAssembly 集成，进一步增强性能。
（字数：约 1250 字）