Webman适合电子签章系统因其异步非阻塞模型可支撑5000+并发、低延迟长连接，内存占用比Laravel低60%，但需自行集成国密SDK实现SM2/SM3签名验签及PKI证书链验证，PDF合成与国密运算须剥离主事件循环。
Webman 为什么适合电子签章系统？
因为签章系统天然需要高并发、低延迟和稳定长连接——比如多人协同签署、实时盖章状态同步、PDF流式渲染，这些场景下 Webman 的异步非阻塞模型比传统 PHP 框架更扛压。它不依赖 Apache/Nginx 的 CGI 模式，而是用 Workerman 底层直接管理 TCP/HTTP/WebSocket 连接，单机轻松支撑 5000+ 并发连接，且内存占用比 Laravel 低约 60%。
但要注意：Webman 本身不内置 PDF 渲染、SM2 签名或印章图像合成能力，这些必须靠扩展或外部服务补足。别指望装完框架就能直接盖章。
签名验签必须自己集成国密算法，不能只靠 JWT
JWT（如 tinywan/jwt 或 yzh52521/webman-jwt-auth）只负责用户会话鉴权，跟电子签章的法律有效性无关。国密验签要验证三层：SM2 签名值、SM3 哈希摘要、以及证书链有效性（含 CRL/OCSP 检查），这些 JWT 插件完全不处理。
- 必须引入合规国密 SDK，例如
gmsslPHP 扩展或php-sm2纯 PHP 实现（注意后者不支持硬件密码机） -
SM2公钥解密后得到的是SM3摘要，需对原始 PDF 内容（不是 Base64 或 URL）重新计算 SM3，二者比对才有效 - 证书验证必须走完整 PKI 流程：检查
notBefore/notAfter、keyUsage是否含digitalSignature、证书链是否可上溯到可信根 CA
前端签名控件如何与 Webman 后端对接？
别让 Webman 直接暴露 Canvas 数据流。常见错误是前端把 canvas.toDataURL() 的 Base64 图片直接 POST 给接口，导致大文件阻塞事件循环、上传超时、内存暴涨。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
正确做法是分层处理：
- 前端用
signature_pad或自研 Canvas 控件，导出为轻量JSON笔迹数据（含坐标点、时间戳、压力值），体积比 PNG 小 90% - Webman 接口接收 JSON，用 GD 或
imagick合成 PNG/SVG，并存入public/signatures/或对象存储 - 盖章动作触发 WebSocket 广播（通过
Worker::connectionMap），通知所有协作方刷新签章位置，而不是轮询 - PDF 合成不要在 Webman 进程里做——调用独立的
pdf-tools服务（如基于 Node.js 的pdf-lib或 Go 的unidoc），避免阻塞主事件循环
生产环境必须绕开 Webman 的默认 HTTP 服务
Webman 自带的 php start.php start 是开发模式，HTTP 服务没有 TLS、无请求体大小限制、无连接复用，直接暴露公网等于裸奔。
上线前必须：
- 用 Nginx 做反向代理，启用
ssl_certificate、client_max_body_size 100M（PDF 上传）、proxy_buffering off（流式响应） - WebSocket 路径（如
/ws）需配置proxy_http_version 1.1和Upgrade $http_upgrade - 禁用 Webman 的
debug模式，关闭display_errors，否则var_dump可能泄露私钥路径或证书内容 - 国密证书（含 SM2 私钥）绝不能放在
app/或config/目录下，应挂载为 Docker secret 或从 KMS 获取
最易被忽略的一点：Webman 的 process 机制虽支持守护进程，但国密运算（尤其是 SM2 签名）CPU 密集，必须单独起 worker 进程绑定 CPU 核心，否则会拖慢整个 HTTP 请求队列。
