Webman不能直接用Supabase Realtime客户端，因其运行于PHP Swoole服务端环境，缺乏浏览器所需的WebSocket、fetch等API，硬集成会报ReferenceError；正确做法是前端直连Realtime，Webman仅作认证代理或调用REST API。
Webman 本身不内置 WebSocket 实时能力，直接集成 Supabase 的 Realtime 功能会失败——因为 Supabase Realtime 依赖客户端主动建立 WebSocket 连接并监听 Postgres 的 WAL 日志变更，而 Webman 默认只处理 HTTP 请求，没有运行在浏览器环境的 JS 客户端上下文。
为什么 Webman 不能直接用 Supabase Realtime 客户端？
Supabase 的 supabase-js 实时订阅（如 from('messages').on('INSERT', ...).subscribe()）本质是浏览器或 Node.js 环境中运行的 WebSocket 客户端，它需要：WebSocket 全局对象、fetch、AbortController 等浏览器 API；Webman 是 PHP Swoole 驱动的常驻进程框架，运行在服务端，没有这些环境。硬塞 supabase-js 到 Webman 中会报 ReferenceError: WebSocket is not defined 或 fetch is not defined。
Webman 正确接入 Supabase 实时数据的路径
必须把实时能力“转嫁”到前端，Webman 只做轻量桥接或兜底同步：
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 前端用
@supabase/supabase-js直连 Supabase Realtime（推荐），Webman 不参与订阅逻辑 - Webman 仅作为认证代理或业务接口：例如用
supabase.auth.api.getUserByCookie()解析前端带过来的sb-access-tokenCookie，校验用户身份 - 若需服务端触发广播（比如审核后通知所有人），用 Supabase 的
supabase.rpc()调用自定义 PostgreSQL 函数，再配合NOTIFY+ Realtime 监听，而非在 Webman 里写 WebSocket 推送 - 避免在 Webman 中尝试用
swoole_websocket_server模拟 Realtime——Supabase Realtime 协议是私有封装的，不是裸 WebSocket，无法兼容
Webman 调用 Supabase REST API 的关键配置点
虽然 Realtime 不行，但 Webman 调用 Supabase 自动生成的 REST API（如 https://xxx.supabase.co/rest/v1/messages）完全可行，注意三点：
- 请求头必须带
Authorization: Bearer <anon_key 或 service_role_key>；anon_key适合公开读写（配合 RLS），service_role_key绕过 RLS，仅限可信服务端使用 - POST/PUT 数据体必须是 JSON，且 Content-Type 设为
application/json，否则 Supabase 返回415 Unsupported Media Type - 查询参数如
?select=*,user(username)支持嵌套字段，但 Webman 的Http::post()默认不自动编码 query，需手动拼接或用http_build_query() - RLS（Row Level Security）策略必须已开启，否则即使带了 token 也会被
401拒绝——这和 Firebase 规则不同，PostgreSQL 的 RLS 是强制开关
容易忽略的 Supabase 权限与 Webman 协作细节
Supabase 的权限模型和 Webman 的中间件逻辑容易错位：
- 前端直连 Realtime 时，RLS 策略基于
auth.uid()自动生效；但 Webman 后端调用 REST API 时，如果用anon_key，RLS 仍生效，而用service_role_key则跳过 RLS——别误以为“后端调用就天然可信” - Webman 中解析 Supabase JWT 的
sb-access-tokenCookie 时，不要自己手写 JWT 解析，应调用supabase.auth.api.getUserByCookie()（需传入 Supabase URL 和service_role_key），否则无法验证签名和过期时间 - Supabase 的
auth.users表默认不开放 SELECT 给 anon 用户，Webman 若想查用户资料，要么开 RLS 策略，要么用service_role_key+ 显式指定 schema（auth.users）
真正卡住人的从来不是“怎么连上”，而是“谁该在哪一层做鉴权、谁该监听哪条 channel、RLS 策略漏写了哪一行”。Webman 和 Supabase 的边界必须划清：实时归前端，认证归 Supabase，Webman 只管业务胶水和兜底逻辑。
