Webman集成Sentry必须手动初始化官方SDK，因非Laravel框架，无Service Provider等机制；sentry/sentry-laravel会报Class not found，且init须在onWorkerStart中执行一次，启用ErrorHandler/ExceptionHandler，DSN需完整协议，CLI脚本末尾须调用flush(2)。
Webman 集成 Sentry 必须手动初始化官方 SDK，不能依赖 Laravel 适配器；否则 ParseError、500 错误和 CLI 任务异常大概率漏报。
为什么不能用 sentry/sentry-laravel
Webman 不是 Laravel，没有 Service Provider、report() 方法或自动异常钩子。装 sentry/sentry-laravel 会直接报 Class not found 或初始化失败，php artisan sentry:publish 命令根本不存在。必须用基础 SDK：composer require sentry/sentry。
Sentry\init() 必须放在 onWorkerStart 里
Webman 是常驻内存模型，worker 启动后长期运行，Sentry\init() 只需执行一次。若错放到 onRequest 或中间件中，每次请求都新建 Client，会导致内存泄漏 + 上报重复。
-
DSN必须带完整协议和路径，例如https://xxx@o123.ingest.sentry.io/456；只填域名或 ID 会静默失效 - 务必启用错误处理器：
$options->setEnableErrorHandler(true)，否则E_WARNING/E_NOTICE不上报 - 务必启用异常处理器：
$options->setEnableExceptionHandler(true)，捕获未 catch 的Throwable - 使用
Hub::setCurrent()替代全局静态调用，避免并发污染
如何给每个请求注入用户 ID、trace_id 等上下文
Webman 没有 Laravel 的 request scope 自动绑定机制，必须在 onRequest 回调中手动 configureScope —— 且不能复用全局 Hub 实例，否则并发请求会互相覆盖上下文。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 在
onRequest中调用\Sentry\configureScope()，传入闭包 - 闭包内用
$scope->setUser(['id' => $userId])注入用户信息 - 用
$scope->setTag('request_id', $request->header('x-request-id'))绑定链路 ID - CLI 脚本末尾必须加
\Sentry\flush(2)，否则进程退出时未发完的事件就丢了
常见漏报场景和修复点
最常被忽略的是三类漏报：PHP 解析错误（ParseError）、HTTP 500 响应、定时任务异常。它们不走正常异常流程，必须靠底层处理器兜底。
-
ParseError属于 PHP 致命错误，仅靠setEnableExceptionHandler不够，必须同时开启setEnableErrorHandler并确保error_types包含E_PARSE - 500 错误往往由框架内部抛出但未被捕获，建议在 Webman 全局异常处理器（如
app/exception/Handler.php）中显式调用\Sentry\captureException($e) - CLI 任务（如定时脚本）独立于 HTTP 生命周期，需在脚本末尾手动
\Sentry\flush(2)，超时时间建议设为 2 秒以上
真正容易出问题的地方不在初始化代码本身，而在于上下文注入时机和 flush 时机——这两个点一旦遗漏，监控就形同虚设。
