核心是服务端边生成、边加密、边分块发送，通过HTTPS+chunked实现流式输出，提升大体积动态脚本的首字节时间和内存效率；需显式设Transfer-Encoding: chunked、禁用缓冲、每块16KB对齐AES-GCM、同步加密封装、附HMAC校验、客户端用ReadableStream流水线解密执行，并启用TLS 1.3、HTTP/2优先级及可选mTLS。
核心在于让服务端边生成、边加密、边分块发送，避免把整个脚本加载进内存再处理。HTTPS 提供传输层加密，而 chunked 保证流式输出，两者结合能显著提升大体积动态脚本（如实时生成的 WASM 模块、混淆 JS、密钥派生代码等）的首字节时间和内存效率。
服务端需主动启用流式响应流程
不能依赖客户端发起 chunked 请求——HTTP/1.1 中 chunked 是服务端单向决定的响应机制。关键操作包括：
- 响应头必须显式设置 Transfer-Encoding: chunked，且不能同时带 Content-Length
- 禁用所有输出缓冲：在 PHP 中调用
ob_end_flush()和flush()；在 Node.js 中用res.write()分批写入；在 Python Flask/FastAPI 中使用StreamingResponse或yield生成器 - 每个 chunk 建议控制在 4–64 KB：太小增加协议开销，太大延迟首屏；对加密脚本尤其推荐 16 KB（便于 AES-GCM 块对齐）
加密逻辑必须与分块节奏同步嵌入
不能“先全量加密再分块”，而要“每块独立加密封装”。例如生成一个动态混淆 JS 脚本时：
- 读取原始脚本片段（如函数体、模块段）→ 用会话密钥 AES-256-GCM 加密 → 附加认证标签（AEAD）→ 封装为 chunk
- 每个 chunk 末尾附带校验字段，如 X-Chunk-HMAC: sha256=xxx（HMAC 密钥由 TLS 会话密钥派生）
- 服务端维持一个轻量上下文（如 chunk 序号、已发字节数），用于断点续传或重试对齐
客户端需适配流式接收与解密
浏览器原生支持 chunked 响应，但解密需手动接管：
- 用
fetch()+response.body.getReader()获取ReadableStream - 用
TransformStream实现“接收 → 解析 chunk 头 → 提取数据 → HMAC 校验 → AES-GCM 解密 → 输出”流水线 - 避免将全部 chunk 缓存在内存：解密后立即执行（
eval()或WebAssembly.instantiateStreaming()）或注入<script>标签
HTTPS 层面需启用关键增强项
仅靠默认 HTTPS 不足以支撑高吞吐流式加密脚本：
- 强制使用 TLS 1.3，启用 0-RTT 数据加速首 chunk 到达（注意重放防护）
- 服务端配置 HTTP/2，并开启 stream priority，确保加密脚本流不被其他资源（如图片、CSS）抢占
- 若脚本含敏感逻辑，建议启用 mTLS，服务端验证客户端证书中是否携带
script_exec权限扩展
