企业官网建设流程全解析

1. 项目概述：为什么技术社区要为公众号扫码登录“重写一次通信逻辑”

最近在帮某技术社区做用户体系升级时，团队内部吵了整整两天——不是争论要不要加公众号扫码登录，而是争论“到底该不该用SSE”。有人坚持用传统轮询，说“稳定、兼容性好、前端不用改太多”；也有人力推WebSocket，觉得“实时性强、听着就高级”。最后我们花了三天时间，在真实用户行为数据和服务器压测结果上反复验证，才把方案敲定为基于SSE（Server-Sent Events）协议的扫码登录链路。这不是跟风，也不是炫技，而是被真实场景逼出来的选择。

这个项目解决的核心问题很具体：技术社区的主力用户是25–38岁的开发者，他们日常高频使用微信，但又极度反感跳转H5、输入手机号、收短信验证码这类中断式登录流程。而公众号原生登录能力受限于微信开放平台的授权范围——它不支持静默获取用户手机号，也不允许直接绑定已有账号体系。所以必须设计一套“扫码即识别身份+本地会话无缝接管”的轻量级通道。关键词里反复出现的“SSE”，正是我们用来承载“扫码状态同步”这一关键环节的技术锚点。

它不是替代OAuth2.0，而是补全OAuth2.0在扫码阶段的体验断层。整个流程中，用户扫的是社区生成的临时二维码，后端通过SSE向已打开登录页的浏览器持续推送“扫码中→已确认→登录成功”三态变更，前端只监听、不轮询、不主动请求。实测下来，从用户扫码到页面自动跳转，平均耗时1.37秒，95分位延迟控制在2.1秒内，比传统3秒间隔轮询快40%以上，且服务器QPS下降62%。适合谁参考？如果你正在做B端后台、开发者工具、技术文档平台这类需要兼顾微信生态又强调响应质感的系统，这个方案可以直接抄作业；如果你是刚接触服务端推送机制的前端同学，这里拆解的每一步都带着参数依据和避坑注释；如果你是架构侧同学，后面会专门讲清楚SSE在长连接资源占用、Nginx代理配置、异常重连策略上的取舍逻辑。

2. 整体设计思路：为什么是SSE，而不是WebSocket或轮询

2.1 三种方案的真实成本对比，不是理论值，是压测数据

我们搭建了三套平行环境，模拟5000并发扫码请求，持续压测15分钟，记录核心指标：

提示：别被WebSocket的“0.42秒”迷惑。它确实快，但代价是：① 每个连接需维持心跳包（默认30秒），5000连接就是每秒166次无意义请求；② 一旦Nginx未正确配置buffering，消息会积压导致延迟突增；③ 前端需自行处理网络闪断后的会话状态恢复，而扫码登录恰恰要求“状态不可丢失”——你不能让用户扫完码，因为网络抖动重连后，系统却忘了他刚点过“确认”。

SSE的优势不在绝对速度，而在确定性交付+低侵入性+服务端可控性。它的协议本质是HTTP长连接，天然兼容所有CDN、WAF、反向代理；消息由服务端单向推送，避免了WebSocket双向通道中“客户端发错序号、服务端状态不同步”的经典陷阱；更重要的是，SSE支持Last-Event-ID断线续传机制——哪怕用户切到微信确认界面时手机锁屏10秒，再回来，浏览器会自动带上上次收到的ID，服务端只需从该ID之后继续推送，状态零丢失。

2.2 技术选型背后的业务约束倒推

很多技术方案失败，不是因为技术不行，而是没看清业务边界。我们当时列出了四条硬约束，直接筛掉了其他选项：

1. 必须支持微信内置浏览器（X5内核）：X5对WebSocket兼容性极差，尤其在安卓低版本上频繁触发onerror且无法捕获具体原因；而SSE在X5中自Android 4.4起就稳定支持，无需polyfill。

2. 扫码页必须能静态部署在CDN：社区前端是纯静态Vue SPA，登录页需直传CDN加速。WebSocket需前端主动建立连接，意味着CDN必须透传WebSocket协议（部分CDN不支持或需额外付费）；SSE则完全走HTTP，CDN只需关闭缓存即可，零配置成本。

3. 服务端不能增加新中间件：现有架构已接入Redis集群和MySQL主从，但拒绝引入RabbitMQ/Kafka等消息队列。SSE的事件广播我们用Redis Pub/Sub实现，复用现有组件，无新增运维负担。

4. 前端不能承担状态同步逻辑：扫码后，用户可能在微信端操作（如取消授权）、也可能在浏览器端操作（如关闭页面）。若用轮询，前端需自己维护“是否已扫码”“是否已确认”“是否超时”三重状态机；SSE则由服务端统一广播状态，前端只做“接收→渲染→跳转”三步，逻辑扁平，不易出错。

2.3 SSE在扫码登录中的角色定位：它只干一件事，但必须干好

很多人误以为SSE是“替代登录”的方案，其实它只是登录流程中的一个状态信使。整个扫码登录链路由四个模块协同完成：

• 二维码生成模块：生成带唯一scan_id的临时二维码（有效期2分钟），存入Redis，设置scan_id: {status: 'waiting', user_openid: null, created_at: timestamp}。
• 微信服务端回调模块：用户在微信中确认后，微信服务器向我们的回调地址推送scan_id和user_openid，我们更新Redis中对应scan_id的状态为confirmed，并发布事件到channel:scan_status_{scan_id}。
• SSE事件广播模块：独立的SSE服务监听Redis频道，收到事件后，按scan_id匹配所有已建立的EventSource连接，向其推送格式化事件（event: status\ndata: {"status":"confirmed","openid":"oxxx"}\n\n）。
• 前端监听模块：登录页初始化new EventSource('/api/sse?scan_id=xxx')，监听message事件，根据data字段更新UI，并在收到confirmed后调用/api/login/bind完成账号绑定与Token签发。

注意：SSE不参与任何鉴权、不存储用户凭证、不生成Token。它只负责把“微信端发生了什么”这个事实，以最小延迟、最高可靠性，告诉“正在等待的浏览器”。这种职责单一性，正是它能在复杂环境中保持稳定的底层原因。

3. 核心细节解析：SSE服务端实现的关键参数与陷阱

3.1 连接保活：不是加心跳，而是理解HTTP超时的本质

SSE连接看似简单，但线上最常遇到的问题是“连接莫名断开”。查日志发现，断开前没有任何错误，就是突然没了。根源在于：HTTP协议本身没有定义“长连接存活时间”，一切由代理层和客户端共同决定。

我们最初在Nginx配置中只写了：

location /api/sse { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; }

结果上线后，连接平均存活时间只有55秒。抓包发现，Nginx在55秒后主动发送了FIN包。翻Nginx文档才明白：proxy_read_timeout默认值是60秒，它控制的是“从上游读取响应的超时时间”，而SSE是上游持续写入，Nginx认为“60秒没新数据，上游挂了”，于是断连。

解决方案不是调大proxy_read_timeout（那会导致故障发现延迟），而是显式声明连接保活意图：

location /api/sse { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; # 关键：禁用Nginx缓冲，避免消息积压 proxy_buffering off; # 关键：设置合理的读超时，但配合服务端心跳 proxy_read_timeout 300; # 5分钟，足够覆盖扫码全流程 # 关键：添加keepalive，复用后端连接 proxy_http_version 1.1; proxy_set_header Connection ''; proxy_set_header Host $host; }

但光靠Nginx还不够。服务端必须主动发送心跳，否则某些CDN或运营商网关会在2分钟内强制断开空闲连接。我们采用的方案是：每45秒发送一条注释事件（comment event）。SSE规范规定，以冒号开头的行是注释，客户端忽略，但能重置所有中间设备的空闲计时器：

# Python Flask示例 from flask import Response, request, stream_with_context import time import json def sse_stream(scan_id): def event_generator(): # 发送初始事件，告知客户端连接建立 yield "event: connect\ndata: connected\n\n" # 每45秒发送一次心跳注释 last_heartbeat = time.time() while True: # 检查Redis中scan_id状态变化 status_data = redis_client.hgetall(f"scan:{scan_id}") if status_data and status_data.get(b'status') != b'waiting': # 有状态变更，推送事件 yield f"event: status\ndata: {json.dumps(status_data)}\n\n" break # 心跳：如果距离上次心跳超过45秒，发送注释 if time.time() - last_heartbeat > 45: yield ": heartbeat\n\n" # 注释事件，客户端忽略 last_heartbeat = time.time() time.sleep(1) # 避免CPU空转 return Response( stream_with_context(event_generator()), mimetype='text/event-stream', headers={ 'Cache-Control': 'no-cache', 'Connection': 'keep-alive', 'X-Accel-Buffering': 'no' # 关键：禁用Nginx缓冲 } )

实操心得：心跳间隔必须小于所有中间设备的空闲超时阈值。我们测试过主流CDN（阿里云、腾讯云、Cloudflare）和三大运营商网关，最短的空闲超时是60秒，所以45秒是安全边际。千万别设成60秒——网络抖动可能导致某次心跳延迟几秒，直接触发断连。

3.2 事件格式与客户端解析：一个换行符引发的血案

SSE事件格式看着简单，但生产环境里，80%的前端解析失败都源于换行符不一致。规范要求事件块以\n\n（两个LF）结尾，但Windows开发环境默认用\r\n，Linux用\n，而Python的print()函数在不同平台行为不同。

我们曾在线上遇到诡异问题：Chrome能正常接收事件，Safari却始终触发onerror。抓包发现，Safari收到的事件末尾是\r\n\r\n，而规范只认\n\n。Safari解析器严格遵循RFC，遇到\r直接报错。

解决方案是服务端强制使用LF换行，并在每行末尾显式添加：

# 错误写法（依赖print自动换行） yield f"event: status\ndata: {json.dumps(data)}" # 正确写法（显式控制换行符） yield f"event: status\ndata: {json.dumps(data)}\n\n" # 确保是\n\n

前端解析也要做容错。不要直接信任event.data，先做清洗：

const eventSource = new EventSource(`/api/sse?scan_id=${scanId}`); eventSource.onmessage = (e) => { try { // 清洗掉可能的\r字符，再解析JSON const cleanData = e.data.replace(/\r/g, ''); const payload = JSON.parse(cleanData); if (payload.status === 'confirmed') { handleLoginSuccess(payload.openid); } } catch (err) { console.error('SSE data parse error:', err, 'raw:', e.data); } };

3.3 连接管理与内存泄漏：如何避免EventSource变成“连接黑洞”

EventSource有个隐藏特性：即使页面跳转或关闭，连接也不会立即释放。浏览器会尝试重连（默认3秒间隔），直到达到最大重试次数（通常3次）或服务端返回非200状态码。

我们初期没处理这个，导致运营同学反馈“登录页打开10次，服务器连接数涨了10倍”。查进程发现，Node.js服务的connections指标持续攀升。

根本原因是：前端创建了EventSource，但没在页面卸载时手动关闭。解决方案是监听beforeunload事件，并显式调用close()：

let eventSource = null; function initSSE(scanId) { eventSource = new EventSource(`/api/sse?scan_id=${scanId}`); eventSource.onopen = () => { console.log('SSE connected'); }; eventSource.onerror = (err) => { console.error('SSE error:', err); }; } // 页面卸载前关闭连接 window.addEventListener('beforeunload', () => { if (eventSource && eventSource.readyState === EventSource.OPEN) { eventSource.close(); } }); // 更保险的做法：路由切换时也关闭（如Vue Router的beforeRouteLeave）

但光关闭还不够。服务端需识别“无效连接”。我们给每个EventSource连接分配唯一client_id，并在Redis中记录：

# 生成client_id并存入Redis client_id = str(uuid.uuid4()) redis_client.setex(f"client:{client_id}", 300, scan_id) # 5分钟有效期 # SSE流中，每次推送前检查client_id是否有效 def sse_stream(client_id, scan_id): if not redis_client.exists(f"client:{client_id}"): return # 客户端已失效，不推送 # ... 推送逻辑

这样，即使前端忘记关闭，5分钟后连接也会被服务端自动清理，避免僵尸连接堆积。

4. 实操过程详解：从零搭建可落地的SSE扫码登录链路

4.1 后端服务搭建：以Python Flask为例的完整实现

我们选用Flask作为SSE服务框架，因其轻量、调试方便，且生态成熟。以下是可直接运行的核心代码（已脱敏，适配生产环境）：

# app.py from flask import Flask, request, Response, jsonify, stream_with_context from redis import Redis import json import time import uuid from datetime import datetime, timedelta app = Flask(__name__) # Redis连接（生产环境建议用连接池） redis_client = Redis(host='localhost', port=6379, db=0, decode_responses=True) # 1. 生成扫码二维码接口 @app.route('/api/qrcode', methods=['POST']) def generate_qrcode(): # 生成唯一scan_id scan_id = str(uuid.uuid4()) # 存入Redis，设置2分钟过期 qrcode_data = { 'status': 'waiting', 'created_at': datetime.now().isoformat(), 'expires_at': (datetime.now() + timedelta(minutes=2)).isoformat() } redis_client.hset(f"scan:{scan_id}", mapping=qrcode_data) redis_client.expire(f"scan:{scan_id}", 120) # 2分钟 # 返回二维码URL（实际应调用微信API生成） qrcode_url = f"https://example.com/qrcode?scan_id={scan_id}" return jsonify({ 'scan_id': scan_id, 'qrcode_url': qrcode_url, 'expires_in': 120 }) # 2. 微信回调接口（模拟） @app.route('/api/wechat/callback', methods=['POST']) def wechat_callback(): data = request.get_json() scan_id = data.get('scan_id') openid = data.get('openid') if not scan_id or not openid: return jsonify({'error': 'invalid params'}), 400 # 更新Redis状态 pipe = redis_client.pipeline() pipe.hset(f"scan:{scan_id}", 'status', 'confirmed') pipe.hset(f"scan:{scan_id}", 'user_openid', openid) pipe.hset(f"scan:{scan_id}", 'confirmed_at', datetime.now().isoformat()) pipe.execute() # 发布事件到Redis频道 redis_client.publish(f"scan_status_{scan_id}", json.dumps({ 'status': 'confirmed', 'openid': openid, 'timestamp': datetime.now().isoformat() })) return jsonify({'success': True}) # 3. SSE事件流接口 @app.route('/api/sse') def sse_endpoint(): scan_id = request.args.get('scan_id') if not scan_id: return jsonify({'error': 'scan_id required'}), 400 # 为每个连接生成client_id，用于连接管理 client_id = str(uuid.uuid4()) redis_client.setex(f"client:{client_id}", 300, scan_id) # 5分钟有效期 def event_generator(): # 发送连接建立事件 yield "event: connect\ndata: connected\n\n" # 记录最后心跳时间 last_heartbeat = time.time() # 监听Redis频道 pubsub = redis_client.pubsub() pubsub.subscribe(f"scan_status_{scan_id}") try: for message in pubsub.listen(): if message['type'] == 'message': try: payload = json.loads(message['data']) # 推送状态事件 yield f"event: status\ndata: {json.dumps(payload)}\n\n" # 重置心跳计时器 last_heartbeat = time.time() except Exception as e: print(f"Parse error: {e}") # 每45秒发送心跳注释 if time.time() - last_heartbeat > 45: yield ": heartbeat\n\n" last_heartbeat = time.time() finally: pubsub.unsubscribe() pubsub.close() return Response( stream_with_context(event_generator()), mimetype='text/event-stream', headers={ 'Cache-Control': 'no-cache', 'Connection': 'keep-alive', 'X-Accel-Buffering': 'no' } ) # 4. 登录绑定接口（扫码确认后调用） @app.route('/api/login/bind', methods=['POST']) def bind_login(): data = request.get_json() scan_id = data.get('scan_id') openid = data.get('openid') # 从Redis获取扫码数据 scan_data = redis_client.hgetall(f"scan:{scan_id}") if not scan_data or scan_data.get('status') != 'confirmed': return jsonify({'error': 'scan not confirmed'}), 400 # 绑定逻辑：查询用户表，生成JWT Token等 # ... 实际业务代码 return jsonify({ 'token': 'your-jwt-token-here', 'user_info': {'nickname': 'tech_user', 'avatar': 'https://...'} }) if __name__ == '__main__': app.run(host='0.0.0.0', port=5000, debug=False)

关键配置说明：

• redis_client.pubsub()用于监听Redis频道，这是SSE事件源的核心。
• stream_with_context()确保生成器在请求生命周期内持续运行，避免协程中断。
• X-Accel-Buffering: no是Nginx兼容的关键Header，必须显式设置。
• 所有Redis操作都用了Pipeline，减少网络往返，提升并发性能。

4.2 前端集成：Vue 3 Composition API的优雅封装

我们用Vue 3的Composition API封装了一个useSSELoginHook，让登录逻辑可复用、易测试：

<!-- Login.vue --> <template> <div class="login-container"> <div v-if="step === 'qrcode'"> <h2>微信扫码登录</h2> <img :src="qrcodeUrl" alt="扫码二维码" class="qrcode" /> <p class="tip">请使用微信扫描二维码</p> <div class="status">{{ statusText }}</div> </div> <div v-else-if="step === 'loading'"> <h2>登录中...</h2> <div class="spinner"></div> </div> </div> </template> <script setup> import { ref, onUnmounted, onBeforeUnmount } from 'vue' import { useSSELogin } from '@/composables/useSSELogin' const { step, qrcodeUrl, statusText, startLogin, stopLogin } = useSSELogin() // 启动登录流程 startLogin() // 页面卸载时停止SSE连接 onBeforeUnmount(() => { stopLogin() }) </script>

// composables/useSSELogin.js import { ref, onUnmounted } from 'vue' export function useSSELogin() { const step = ref('qrcode') // 'qrcode' | 'loading' | 'success' const qrcodeUrl = ref('') const statusText = ref('请使用微信扫描二维码') let eventSource = null let scanId = null // 启动登录 const startLogin = async () => { try { // 1. 请求生成二维码 const res = await fetch('/api/qrcode', { method: 'POST' }) const data = await res.json() scanId = data.scan_id qrcodeUrl.value = data.qrcode_url // 2. 初始化SSE连接 eventSource = new EventSource(`/api/sse?scan_id=${scanId}`) // 3. 监听事件 eventSource.onmessage = (e) => { try { const payload = JSON.parse(e.data.replace(/\r/g, '')) if (payload.status === 'confirmed') { step.value = 'loading' statusText.value = '正在绑定账号...' // 调用绑定接口 fetch('/api/login/bind', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ scan_id: scanId, openid: payload.openid }) }) .then(res => res.json()) .then(tokenData => { // 存储Token，跳转首页 localStorage.setItem('auth_token', tokenData.token) window.location.href = '/' }) .catch(err => { statusText.value = '登录失败，请重试' console.error('Bind error:', err) }) } } catch (err) { console.error('SSE parse error:', err) } } eventSource.onerror = (err) => { console.error('SSE connection error:', err) statusText.value = '连接异常，请刷新页面' } eventSource.onopen = () => { console.log('SSE connected') } } catch (err) { console.error('Start login error:', err) statusText.value = '获取二维码失败，请重试' } } // 停止登录（关闭SSE） const stopLogin = () => { if (eventSource && eventSource.readyState === EventSource.OPEN) { eventSource.close() eventSource = null } } // 页面卸载时自动停止 onUnmounted(stopLogin) return { step, qrcodeUrl, statusText, startLogin, stopLogin } }

实操心得：

• Vue的onUnmounted钩子比beforeunload更可靠，因为它在组件销毁时必然触发，而beforeunload在SPA路由切换时不一定执行。
• JSON.parse(e.data.replace(/\r/g, ''))是必备容错，已在多个真实机型上验证有效。
• localStorage.setItem('auth_token', tokenData.token)是简化写法，生产环境应使用HttpOnly Cookie或更安全的存储方案。

4.3 Nginx生产配置：绕过所有常见代理陷阱

这是我们在生产环境验证过的Nginx配置，已屏蔽所有可能导致SSE失效的默认行为：

# /etc/nginx/conf.d/sse.conf upstream sse_backend { server 127.0.0.1:5000; keepalive 32; # 保持32个长连接 } server { listen 443 ssl http2; server_name example.com; # SSL配置（略） location /api/sse { proxy_pass http://sse_backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 关键：禁用所有缓冲 proxy_buffering off; proxy_buffer_size 4k; proxy_buffers 8 4k; proxy_busy_buffers_size 8k; # 关键：设置合理的超时 proxy_connect_timeout 5s; proxy_send_timeout 300s; # 匹配后端proxy_read_timeout proxy_read_timeout 300s; # 5分钟，覆盖扫码全流程 # 关键：禁用缓存 proxy_cache off; add_header Cache-Control "no-cache, no-store, must-revalidate"; add_header Pragma "no-cache"; add_header Expires "0"; # 关键：确保X-Accel-Buffering生效 proxy_hide_header X-Accel-Buffering; add_header X-Accel-Buffering "no"; } # 其他API路由（略） }

注意事项：

• proxy_http_version 1.1和proxy_set_header Connection 'upgrade'必须同时存在，否则Nginx会降级为HTTP/1.0，导致SSE失效。
• proxy_buffering off是核心，若开启，Nginx会缓存SSE消息直到缓冲区满或超时，彻底破坏实时性。
• add_header X-Accel-Buffering "no"是针对Nginx的特殊Header，强制禁用其内部缓冲，比proxy_buffering off更彻底。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 问题速查表：从现象到根因的快速定位

5.2 独家避坑技巧：来自三次线上事故的教训

技巧1：用Redis的EXPIRE代替应用层定时器
初期我们用Python的threading.Timer来清理过期scan_id，结果在高并发下，Timer对象堆积导致内存泄漏。后来改为：所有scan_id写入时直接设置EXPIRE 120，依赖Redis自动清理。既省去应用层维护成本，又100%可靠。记住：状态过期，交给存储层，别自己造轮子。

技巧2：SSE连接数监控必须包含client_id维度
我们曾只监控netstat -an \| grep :5000 \| wc -l，发现连接数稳定在200左右，但用户投诉“扫码没反应”。深入排查才发现，这200个连接里，180个是已失效的client_id（用户关闭页面后未关闭连接）。现在我们用redis-cli keys "client:*" \| wc -l实时监控有效连接数，并告警当client:*数量超过阈值（如500）时触发扩容。

技巧3：前端重连逻辑必须带退避指数
EventSource默认重连间隔是5秒，但若服务端临时宕机，5000个客户端同时在5秒后重连，会造成雪崩。我们在前端加了指数退避：

let retryCount = 0 eventSource.onerror = () => { retryCount++ const delay = Math.min(1000 * Math.pow(2, retryCount), 30000) // 最大30秒 setTimeout(() => { eventSource = new EventSource(`/api/sse?scan_id=${scanId}`) }, delay) }

这样，第一次失败后等1秒，第二次等2秒，第三次等4秒……避免冲击。

技巧4：扫码页必须做“连接健康检查”
我们发现，约3%的用户扫码后，页面卡在“请扫码”状态。抓包发现，是SSE连接建立了，但服务端没推送任何事件。根因是：用户网络环境差，TCP连接虽通，但HTTP流阻塞。解决方案是在页面加载后，发起一次轻量级健康检查：

// 页面加载后立即检查SSE是否可用 fetch('/api/sse/health') .then(res => res.json()) .then(data => { if (!data.ok) { statusText.value = '服务暂时不可用，请稍后重试' throw new Error('SSE health check failed') } })

/api/sse/health接口只返回{ok: true}，不走SSE流，快速验证后端服务可达性。

5.3 性能压测实录：5000并发下的真实表现

我们用k6进行了三轮压测，环境为：2核4G云服务器，Nginx + Flask + Redis单机部署。

第一轮：基础SSE连接建立

• 场景：5000个虚拟用户，每秒100个并发，建立SSE连接
• 结果：连接全部建立成功，平均耗时210ms，95分位340ms
• 瓶颈：Redis连接数（默认10000），调整maxclients后解决

第二轮：扫码状态推送

• 场景：5000个已建立连接，模拟1000次扫码确认（每秒20次）
• 结果：事件从Redis发布到前端接收，平均延迟1.28秒，P95为2.05秒
• 关键发现：当pubsub.listen()循环中加入time.sleep(0.01)，延迟反而降低——因为减少了CPU争抢，让I/O更及时

第三轮：混合压力（连接+推送+绑定）

• 场景：5000连接中，每秒20次扫码，每秒10次/api/login/bind调用
• 结果：CPU峰值72%，内存占用稳定在1.2G，无连接丢失，所有业务请求成功率99.98%
• 结论：当前架构可支撑日活50万的技术社区，扫码登录模块无需扩容

最后分享一个小技巧：在SSE服务启动时，主动推送一条event: ping\ndata: {ts: ${Date.now()}}\n\n，