thinkphp3 redis序列化和反序列化
在老系统重构迁移至 ThinkPHP 6 (TP6) 的过程中，ThinkPHP 3 (TP3) 的 Redis 序列化历史遗留问题是最核心的连环坑之一。 TP3 的 S('key', $value) 缓存方法和底层 Redis 驱动，在存储非字符串（如数组、对象）时，有一套独特的序列化行为。如果不
「技术」下的文章
Table 空间极易发生哈希冲突并溢出
既然你没有在业务中主动调用 Room，只使用了全局广播，那么这个问题就非常明确了：即使你不用房间功能，think-swoole 只要开启了 WebSocket，底层就会强行初始化并注入一个名为 Room 的驱动组件。 [1] 框架底层默认使用 table 类型来作为 Room 的存储介质。当进行全局
将监控程序直接跑在云端
将监控程序直接跑在云端（服务器），最大的好处是不需要保持个人电脑开机，能够 24 小时稳定运行。 由于在云端无法像浏览器插件那样直接复用你的日常登录状态，我们需要使用 headless（无头）浏览器技术（如 Node.js 的 Puppeteer 或 Python 的 Playwright），并在服
AI 驱动型 Facebook 群组关键词监控 Chrome 浏览器插件
自己开发一个类似 One Stop Social 的 Facebook 群组关键词监控工具，最核心的难点在于 Facebook 官方 API 极其严格。由于 2018 年的数据隐私风波，官方彻底关闭了普通用户通过 API 读取他人群组帖子的权限。 因此，自主开发只能采用 “自动化模拟（爬虫/自动化脚
Redis 的发布/订阅（Pub/Sub） 机制
在 think-swoole 中，如果项目开启了多个 Worker 进程或者部署了多台服务器，直接遍历 server->connections 只能触及当前进程下的连接。 要实现跨进程、跨服务器的广播，最成熟的方案是引入 Redis 的发布/订阅（Pub/Sub） 机制。这类似于 Socket.io
在 think-swoole 框架中融入 Custom Process（自定义进程）
在 think-swoole 框架中融入 Custom Process（自定义进程） 需要特别注意生命周期。因为 think-swoole接管了 Swoole\Server 的创建与启动，我们不能直接 $server->addProcess()，而是必须在 swoole.init 事件中，将自定义进
Swoole 的自定义进程（Process）
你目前是通过 think-swoole 框架提供的沙箱（Sandbox）在 swoole.init 事件中，使用主服务器的 $server->addListener(...) 来动态监听 RPC 端口（9513）。 正如之前分析的，$server->addListener() 产生的子端口，无法通过
为 RPC 端口和 Websocket 端口配置独立的 Worker 进程
在标准的 Swoole 中，子服务器端口（listen 产生的 Swoole\Server\Port）只能单独设置网络协议参数，无法直接通过 set(['worker_num' => X]) 来独立设置 Worker 进程数量。也就是说，默认情况下它们必然会共享主服务器的 Worker 进程。 为了
think-swoole 框架底层的一个“隐藏陷阱”
在 think-swoole 的底层实现中，当你调用 $websocket->to('room')->push($data) 时，由于 push 方法需要向特定的 FD 直接发送原始数据，框架为了保证主 Worker 进程不被网络 I/O 阻塞，在底层确实会自动把发送任务投递给 Task 进程去异步
think-swoole 自带的 Room
改用 think-swoole 自带的 Room（房间） 机制是解决线上高频广播丢包、阻塞的最正确姿势。 因为 Room 的底层完全基于 Swoole Table（内存共享表） 实现。当你要全员广播时，它不需要走传统的 Task进程，也不需要通过复杂的管道（Pipe）跨进程通信，更不需要你在代码里写