更新日志

• v0.4.04

  聊天首屏加速 + 视频发送上限 10MB→50MB

  随交付包发布

  性质：性能优化 + 缺陷修复。用户反馈"聊天初次加载资源缓慢""视频发送失败"。

  查看完整变更

  性质：性能优化 + 缺陷修复。用户反馈"聊天初次加载资源缓慢""视频发送失败"。 无表结构变更、无依赖变更。

  一、视频发送失败：根因是 10MB 上限（实测取证）

  实测	结果
  小视频 mp4（11 KB）/ iPhone 风格 .mov / .webm（29 KB）	上传 成功 ✓
  206 MB 视频（手机常见量级）	FAIL：文件大小不能超过 10MB ← 用户遇到的正是这个
  服务端白名单	`video/mp4	webm	ogg	quicktime`（不含 .mov 常见别名 m4v/3gp）
  前端选择器	accept="image/jpeg,…,video/mp4,video/webm" → 手机相册里的 .mov/.m4v/3gp 选不到

  修复：

  • 新增单一配置源 config/config.php：CHAT_MEDIA_MAX_SIZE = 50MB、CHAT_MEDIA_MAX_TEXT = '50MB'； 服务端校验（processChatMediaUpload）与前端（AGENT_CONFIG.chatMediaMaxSize/Text）都读它，不再两处硬编码，改一处即同时生效。
  • 视频白名单扩展：+ video/x-m4v, video/3gpp, video/mpeg, video/x-matroska（并补全扩展名降级映射与落盘扩展名）。
  • 前端选择器放开为 image/*,video/*（手机录制的 .mov/.m4v/3gp 也能选到）。
  • 超限提示带上实际大小与上限：文件 206.1MB 超过上限 50MB，请压缩后再发…；错误 toast 停留 2s → 4.5s（原先太短，用户没看到原因）。
  • messages.php 同步使用同一上限与提示文案。

  二、聊天初次加载缓慢：改成"空闲预热"

  实测：12 个插件资源（im-sdk + 6 个模块 + 5 个 CSS）合计约 136KB，全部 200、单文件 0.9~1.7ms（服务端不慢）； 问题在于历史行为是"用户点开面板才去下载这 12 个文件"，首次打开要等一整轮下载 + 执行。

  修复：tab-card.js 在页面空闲时用 <link rel="prefetch"> 预热这 12 个资源 （URL 与 loader 完全一致，含 ?v= 版本号 → 命中 nginx 30 天强缓存），首次点开即秒开；仅预取不执行，不影响首屏渲染。 verify_final404.py 增加断言：预热清单必须覆盖 im-sdk.js 的 cssFiles + jsFiles（防止两份清单漂移）。

  三、去掉重复轮询

  tab-card.js 与 im-sdk.js 此前各有一个 20s 轮询都请求 ajax-unread.php（双倍请求）。 现在 tab-card 拉到数据后广播 im:badge:data，im-sdk 直接复用（30s 内跳过自己的请求，仍作为无 tab-card 场景的兜底）。

  四、附带修掉的服务器配置缺陷

  php.ini 第 830 行被写坏：upload_tmp_dir="C:/Temp"\n → 值变成不存在的 C:/Temp\n （PHP 静默回退到系统临时目录，open_basedir 未包含该目录时大文件上传会失败）。 已修正为 upload_tmp_dir = "C:/Temp" 并创建目录；同时 max_input_time 100 → 300（大文件上传更稳）。 注意：php.ini 改动需重启 php-fpm 才生效（见交付说明中的一键脚本）。

  实测数据（同步后）

  项目	结果
  206MB 视频	旧：文件大小不能超过 10MB（拒） → 新：提示实际大小与 50MB 上限
  20MB 视频	新：上传成功（v0.4.03 时会被拒）
  首次打开聊天	资源已预热 → 直接命中缓存

• v0.4.03

  修复：聊天发视频/图片时"返回列表"导致发送中断

  随交付包发布

  性质：缺陷修复。复现路径：在聊天窗口选择视频 → 上传过程中点"返回联系人列表" → 提示一直停在"上传中…"，

  查看完整变更

  性质：缺陷修复。复现路径：在聊天窗口选择视频 → 上传过程中点"返回联系人列表" → 提示一直停在"上传中…"， 之后该聊天模块再也加载不出消息（重新进入会话也是空的），看起来像"发视频把聊天搞坏了"。 无表结构变更、无依赖变更、无服务端逻辑变更。

  类别	根因（实测确认）	修复
  🔴 状态标志泄漏（主因）	assets/im-plugin/modules/chat.js 的 _loadMessages() 顺序为"先置 _loadingMessages = true，再 if (!area) return"。上传中返回列表时 _renderContactsView() 已把 DOM 重建、#imChatMsgArea 不存在 → 早退时标志永远停在 true，此后 _loadMessages() 全部被拦，连 4 秒轮询与重新进入会话都失效	调整顺序：先检查容器，再置标志（早退不再污染状态）
  🔴 完成回调与视图耦合	上传成功后直接调 self._loadMessages()，而 _backToContacts() 已把 _chatWith 置空 → 命中上面那个泄漏	上传时固定 receiverId；完成后按当前视图分流：仍在该会话→刷新消息；已切走→刷新联系人列表 + 记录待刷新会话（下次打开自动加载），并广播角标刷新
  🟠 无进度、无中断保护	用 fetch 上传，只有一句"上传中..."；用户以为卡住就切走/刷新，而浏览器会直接中断未完成的上传 → 视频静默丢失	改用 XHR：upload.onprogress 显示百分比（视频/图片分别提示）、onerror/onabort 明确报错、上传中注册 beforeunload 拦截离开/刷新（完成后自动解绑）
  🟠 失败无原因	失败只提示"上传失败"	展示服务端原因（如"文件大小不能超过 10MB"）与 HTTP 状态
  🟠 messages.php 同样风险	发送走 fetch 无进度；离开页面静默丢上传；报错是英文 alert('send error: ...')	改为 XHR：按钮显示"视频上传 42%"、上传中拦截离开、中文错误提示（含服务端原因），完成后恢复按钮状态
  缓存	chat.js 是强缓存资源	IM_BUILD 20261002-2 → 20261002-3

  服务端复核（真实上传实测）：用 ffmpeg 生成 1 秒 MP4（5,389 字节）以 multipart 直接 POST 到 ajax-chat-send.php： 返回 {"success":true,"media_type":"video","media_url":"/uploads/chat/2026/10/chat_1_…mp4"}，文件落盘、chat_media 新增记录 ✓（测试数据已清理）。 线上此前已有的两条视频消息（id 267/268，含 FFmpeg 生成的封面）也证明服务端视频链路本身正常 —— 问题纯在客户端状态机。

  回归测试（Node + DOM 桩，跑真实模块代码）：qdcms-release/test-chat-upload.js，19/19 通过，含对照用例 （用旧顺序的等效逻辑证明该用例确实能捕获"标志卡死"缺陷）： 视图切走后不置卡死标志 / 上传中有进度与离开拦截 / 返回列表后完成→"已发送给「对方」"+刷新列表+记录待刷新 / 仍在该会话→立即刷新消息 / 服务端错误文案透传 / 失败后解除上传态。

• v0.4.02

  全站资源传输优化：首页 717 KB → 10 KB

  随交付包发布

  性质：性能优化。以实测数据驱动，优化静态资源与传输层。

  查看完整变更

  性质：性能优化。以实测数据驱动，优化静态资源与传输层。 无表结构变更、无依赖变更、无业务逻辑变更。

  类别	实测问题	优化
  🔴 静态图过大	assets/images/qdcms-logo.png 1024×1024 / 368 KB、favicon.png 1024×1024 / 302 KB，而页面按 32px 显示 → 首页 717 KB 中 670 KB 是这两张图	logo 256²（-98.2% → 6.7 KB）、favicon 180²（-98.4% → 4.8 KB）；保留原路径与透明通道，15 处引用无需改动；原图备份在 qdcms-release/asset-backup/
  🟠 静态资源无缓存头	/assets/**、/uploads/** 只有 ETag，没有 Cache-Control/Expires → 每次导航都要条件请求	nginx.conf.example 内置 expires：CSS/JS/im-plugin 30 天（由 assetVersion() 追加 ?v= 保证失效）、图像与上传内容 7 天；access_log off；qdcms-deploy.ps1 生成的 vhost 同步内置
  🟠 上传体积不一致	nginx client_max_body_size 50m vs php.ini post_max_size 600M / upload_max_filesize 500M → 大视频上传被 nginx 先拒（413）	对齐为 600m
  🟡 gzip 未调优	gzip_comp_level 2；gzip_types 缺 application/json、image/svg+xml、text/xml	等级 5 + 补类型（AJAX 的 JSON 响应同样受益）
  🟡 静态文件 IO	每次请求都要 stat 磁盘	open_file_cache max=10000 inactive=30s / valid 60s / min_uses 2
  新增工具	客户侧可能同样存在超大静态图	install/optimize-static-images.php（CLI，GD，默认只预演，--apply 才写盘，原图自动备份；实测 2400×1600 JPEG 120 KB → 3.4 KB）
  新增文档	—	docs/传输优化说明.md：审计数据、优化清单、效果对照、复验命令
  已达标项	上传 MP4 均为 faststart（moov 前置）、Range 返回 206、内容图走 img-proxy.php（缩放 + WebP 缓存）	无需改动
  效果	首页传输量（HTML + 14 资源，压缩后）	717.4 KB → 10.2 KB（-98.6%）；二次访问在缓存有效期内 0 请求

• v0.4.01

  全站通知角标修复：好友请求角标 + 角标实时同步

  随交付包发布

  性质：缺陷修复。用户反馈"接受好友请求后角标不消失""已读还亮灯"。逐条实测后的结论与修复如下。

  查看完整变更

  性质：缺陷修复。用户反馈"接受好友请求后角标不消失""已读还亮灯"。逐条实测后的结论与修复如下。 无表结构变更、无依赖变更、无 Go 侧改动。

  类别	实测发现	修复
  🔴 好友角标在浮窗永远不亮	assets/js/tab-card.js 一直在读响应里的 friend_requests / friend_unread，但 ajax-unread.php 从未返回这两个字段 → 浮窗好友角标恒为 0；非 messages.php 页面完全看不到有好友请求	ajax-unread.php 返回 friend_requests（收件方向待处理数）并把好友请求计入 total_unread
  🔴 接受好友后浮窗角标不刷新	插件内"接受/拒绝"后广播 im:badge:refresh，但只有 im-sdk.js 响应该事件、且只更新站内信与聊天角标；好友角标只能等 tab-card.js 的 60 秒轮询	im-sdk.js 的 loadBadges() 同时更新好友角标；tab-card.js 自身也监听 im:badge:refresh 立即刷新（并把轮询 60s→20s）
  🟠 好友角标与聊天角标重复计数	messages.php 的好友角标 = 待处理请求 + 好友发来的未读聊天，而后者与"聊天"角标同为一份数据 → 一条未读聊天同时点亮两个角标	好友角标改为只统计待处理好友请求
  🟠 页面角标不会自更新（"已读还亮灯"的主因）	messages.php 的角标在服务端渲染一次后就不再变化：在浮窗里读完消息/接受好友后，本页角标仍亮着，必须手动刷新	messages.php 新增角标实时同步：每 20 秒轮询 ajax-unread.php 并就地更新三处角标（站点隐藏时暂停、切回立即补一次、im:badge:refresh 时立即同步）；数量为 0 时自动移除角标元素
  🟠 性能	getChatContacts() 的 msg_info 子查询没有用户过滤，对 chat_messages 整表做 GROUP BY（每次打开 messages.php 都全表聚合）	子查询补 WHERE sender_id = ? OR receiver_id = ?（结果口径不变，实测未读计数仍正确）
  复核结论	用隔离测试站逐步复现并验证：发请求 → ajax-unread 返回 friend_requests:1、messages.php 好友角标=1；接受 → friend_requests:0、角标消失；站内信未读=1 → 打开详情后=0（角标与浮窗数据源同步归零）；getChatContacts 未读计数在有/无未读聊天时分别为 1/0 ✓	—

  复盘：接受好友请求本身是能生效的（线上实测 {"success":true,"msg":"已添加好友"}，friendships 状态 0→1、角标立刻清零）。 用户看到"角标不消失"的真实原因是角标刷新链路的三个断点：浮窗数据源缺字段、插件刷新漏好友、页面角标不自更新。 另注：IM_BUILD 已由 20261002-1 递增为 20261002-2（本次改了 im-sdk.js 这一强缓存资源）。

• v0.4.00

  客户安装验收：修复装完无锁 / 缺 uploads 子目录 / 自检解析受 stderr 污染

  随交付包发布

  性质：交付可用性修复。以"客户视角"从零验收（解压 → 建库 → CLI 安装 → 登录 → 后台 → 聊天 → 自检）后

  查看完整变更

  性质：交付可用性修复。以"客户视角"从零验收（解压 → 建库 → CLI 安装 → 登录 → 后台 → 聊天 → 自检）后 修复 3 个"装完不够干净"的问题，并新增《客户安装验收清单》。无表结构变更、无依赖变更。

  类别	发现	修复
  🟠 装完无安装锁	install/auto-install.php 把锁写在 install/install.lock，第 5 步清理安装文件时又 unlink 掉 → 站点根无锁：检测页报"未锁定"，且安装向导可被重复执行	锁改写到站点根目录 install.lock（与浏览器向导口径一致，内容含时间戳 + X-Dream CMS Installed），并保留；同时兼容写一份 install/install.lock 供旧检查读取
  🟡 缺 uploads 子目录	装完只有 uploads/agent-icons，检测页提示"缺子目录: covers,avatars,moments,dramas,ads,_cache"	安装脚本自动创建标准子目录（幂等）
  🟠 自检误报	未打 Windows 补丁的全新站点上，SystemRequirements 会向 stderr 输出 POSIX 命令噪音（cmd.exe "The system cannot find the path specified."），自检用 2>&1 捕获导致 JSON 解析失败，误报"检测注册表 FAIL"并打印整段 JSON	注册表结果改为写 JSON 文件后读取（stderr 丢弃），并保留"从 stdout 截取最外层 JSON"的兜底；另对敏感路径可下载的情况附"当前响应服务器"提示（PHP 内置服务器/Apache 环境不加载 nginx 规则）
  新增文档	客户不清楚"装完能不能直接用、还差什么"	新增 docs/客户安装验收清单.md：前置条件、两种安装方式（向导 / CLI）、装完即可用清单、可选增强对照表（未装时的表现 + 启用方式）、装完必做两件事、验收命令与期望输出、本次实测结论
  验收实测	Windows + 宝塔 nginx + PHP 8.0.28 + MySQL 8.0.29，全新库/全新目录	CLI 安装 50 张表 + 管理员（role=9 靓号 10000）+ 配置 + 锁 + uploads 子目录；首页完整渲染（30.9 KB、版本号正确、AGENT_CONFIG 正常）；登录 302 → 后台 200；messages.php 200 且加载 IM 插件与 4 秒轮询；ajax-chat-history.php 正常；令牌接口在无 GO_API_KEY 时返回 enabled:false（自动降级轮询）；自检 20 PASS / 3 WARN / 8 INFO，结论 PASS，退出码 0（3 项 WARN = SMTP、FFmpeg、Go 产物，均为可选组件）

• v0.3.99

  C 档生产链路实测通过 + 修复推送未被调用的加载问题

  随交付包发布

  性质：C 档上线验证与修复。生产链路端到端实测通过（约 28 ms）。

  查看完整变更

  性质：C 档上线验证与修复。生产链路端到端实测通过（约 28 ms）。 无表结构变更、无依赖变更、Go 侧无改动。

  类别	变更	升级动作
  🔴 修复	ajax-chat-send.php 中的实时推送此前被静默跳过：GoAdapter.php 不在 includes/functions.php 的模块清单里，导致 goAdapter() 未定义，被 function_exists() 守护吞掉。表现为"SSE 连接正常、发消息却收不到事件"（轮询仍正常，故不易察觉）。现改为在发布前显式 require_once includes/GoAdapter.php（带 is_file + function_exists 双重守护）	覆盖升级（必须，否则 C 档推送不生效）
  实测	生产链路：user2 订阅 → /api/im/stats 显示 connections:1 → user1 真实 AJAX 发送（47 ms）→ user2 约 28 ms 收到 event: chat；事件负载仅含 from/from_name/preview/media/at（不含正文）；/im-stream 无令牌探测 403（反代与令牌校验同时生效）	无
  文档	docs/聊天即时通信说明.md 第六节补充"生产链路"实测行（延迟、订阅、负载结构）	无
  排障提示	若"订阅成功但收不到推送"，按序检查：① GO_API_KEY 两侧一致；② Go 是否为新 exe（/api/im/stats 返回 JSON 而非 404）；③ nginx /im-stream 是否 proxy_buffering off；④ PHP 是否成功调用 /api/im/publish（本次即栽在第 ④ 步的模块加载上）	无

• v0.3.98

  按独立复核意见修复：死选择器 / 标题闪烁可达性 / 发布顺序清单

  随交付包发布

  性质：复核整改。v0.3.96–v0.3.97 的聊天 A+B+C 经独立复核 8/8 断言全部 VERIFIED，

  查看完整变更

  性质：复核整改。v0.3.96–v0.3.97 的聊天 A+B+C 经独立复核 8/8 断言全部 VERIFIED， 复核另报 3 个问题，本版修复。无表结构变更、无依赖变更、无 Go 侧改动。

  类别	复核发现	本版修复
  死选择器	im-modules.css 中 .chat-msg-row .msg-read 永不生效（该文件只注入 IM 插件 Shadow DOM，messages.php 并不加载它）	messages.php 两处已读标记改为内联样式（服务端渲染 + AJAX 重渲染）；im-modules.css 移除那半条无效选择器并加注释说明
  标题闪烁不可达	两处 tick 均先 if (document.hidden) return，而切回时又立即清标题 → "隐藏时闪烁"只在请求/响应竞态窗口才可能命中	后台标签页改为降频到约 16 秒一次仍拉取（4 次 tick 执行 1 次），使提示真正可达，同时保持低开销；SSE 推送路径本就可达
  发布顺序	实测 tab-card.js（IM_BUILD）曾晚于 im-sdk.js 约 2 分钟上线，窗口内老用户仍用旧插件包	docs/打包说明.md 发布清单新增显式要求：tab-card.js 必须与 assets/im-plugin/** 改动同批或先行上线
  复核确认项	空增量轮询 128 B（对照全量 30 条 16,567 B，约 129×）；无未读 Com_update +0、有未读 +1；peer_read_id 未读时 0、对方读取后等于己方消息 id；before_id 分支不写库；增量满 50 条回退整页重载；分页与视频付费/封面/baseUrl 区块未被破坏；php -n -l / node --check（含渲染后页面抽取的内联脚本）全部通过	无（已确认）
  安全整改	复核发现测试会话残留仍有效（sess_qdcmstest0001 绑定 user_id=1 管理员）	已立即删除两个测试会话文件与工作区凭据文本，并复验返回 not_logged_in；我方测试流程增加"测试会话用后即删"

• v0.3.97

  聊天 C 档：Go SSE 实时推送网关

  随交付包发布

  性质：实时能力补齐。在 A+B 的 4 秒轮询之上增加 SSE 推送通道，端到端延迟由秒级降到毫秒级；

  查看完整变更

  性质：实时能力补齐。在 A+B 的 4 秒轮询之上增加 SSE 推送通道，端到端延迟由秒级降到毫秒级； 轮询保留为兜底，任何异常都不影响消息投递。无表结构变更。

  类别	变更	升级动作
  Go 服务	新增 go-service/im_hub.go（按用户多路订阅的进程内 pub/sub，非阻塞投递）与 go-service/im_sse.go：GET /im/stream（SSE，短时令牌鉴权、20 s 心跳、X-Accel-Buffering: no）、POST /api/im/publish（内部发布，走既有 CSRF+HMAC 鉴权与 IP 白名单）、GET /api/im/stats（诊断）	需重新编译：go build -trimpath -ldflags "-s -w" -o x-dream-go.exe .
  PHP	新增 ajax-im-token.php（签发短时令牌 `HMAC-SHA256(GO_API_KEY, "im:<uid>	<ts>")，返回同源订阅 URL；未配置密钥返回enabled=false）；includes/GoAdapter.php新增imPublish()；ajax-chat-send.php` 落库后发布事件（失败静默跳过，不影响投递）	覆盖升级
  前端	新增 assets/im-plugin/core/im-sse.js（令牌 → EventSource → 事件分发；指数退避重连并重新取令牌；不支持/未启用时静默退出）；im-sdk.js 加载并启动、收到推送即时刷新徽标；chat.js 收到推送立即增量拉取（不必等 4 秒 tick）；messages.php 亦引入并按当前会话刷新	覆盖升级
  nginx	新增 location = /im-stream 反代到 127.0.0.1:8080/im/stream，必须 proxy_buffering off + access_log off（令牌在查询串）。nginx.conf.example 与 qdcms-deploy.ps1 生成的 vhost 模板均已内置	已有站点需补该 location 并重载 nginx
  安全	浏览器不接触 GO_API_KEY；令牌 300 s 且与 user_id 绑定；签名/时效任一不符即 403；密钥为空或默认值时直接禁用推送；事件负载只含发送者/预览片段/媒体类型/时间，不含正文全文	无
  降级	未配置密钥、Go 未部署、连接中断、浏览器不支持 → 一律静默降级为 4 秒轮询	无
  文档	docs/聊天即时通信说明.md 新增第六节（数据流图、接口契约、安全设计、降级矩阵、实测数据、部署要点）；docs/Windows部署说明.md 第六节补充 SSE 反代提示；docs/打包说明.md 关键文件清单加入 C 档文件	无
  自检	本机实测：令牌三态校验均 403；订阅返回 event: ready；发布 delivered:1（无订阅者 delivered:0）；5 次端到端延迟 14/16/17/24/29 ms；中文与 emoji 无损；旧 exe（无该端点）时 ajax-chat-send.php 静默跳过、消息照常落库。php -n -l 全部通过；node --check 覆盖新增与改动的 JS；Go go build 通过	无

• v0.3.96

  聊天即时通信优化 A+B：4 秒增量轮询 + 已读回执

  随交付包发布

  性质：功能/性能优化。原实现为 15 秒全量轮询、聊天主页完全不刷新、每次轮询都写库、无已读回执。

  查看完整变更

  性质：功能/性能优化。原实现为 15 秒全量轮询、聊天主页完全不刷新、每次轮询都写库、无已读回执。 本次为 A 档（延迟）+ B 档（流量/写放大/回执） 改造；C 档（Go SSE 推送）另行排期。无表结构变更、无依赖变更。

  类别	变更	升级动作
  A1 延迟	会话窗口轮询 15 s → 4 s（assets/im-plugin/modules/chat.js）	覆盖升级
  A2 主页	messages.php 新增 4 秒增量轮询（原来打开聊天页也收不到新消息，必须手动刷新）	覆盖升级
  A3 可见性	后台标签页暂停轮询（浏览器会节流定时器），visibilitychange 切回立即补拉；隐藏期间有新消息则标题闪烁	覆盖升级
  A4 徽标	未读徽标 60 s → 20 s，隐藏时跳过（assets/im-plugin/core/im-sdk.js）	覆盖升级
  B1 增量接口	ajax-chat-history.php 支持 since_id：只返回更新的消息，空轮询响应 15,328 B → 128 B；增量达 50 条时前端退回整屏重载	覆盖升级
  B2 去写放大	仅在"确有对方发来的未读消息"时才 UPDATE … is_read=1（原为每次轮询都写）；实测无未读时 3 次轮询 Com_update 增量 0	覆盖升级
  B3 排序	getChatHistory() 由 ORDER BY created_at 改为 ORDER BY id（秒级时间戳同秒乱序问题）	覆盖升级
  B4 已读回执	历史接口新增 peer_read_id（我已发送且对方已读的最大消息 id）；己方气泡显示"已读/未读"（.msg-read[data-read]，含样式）	覆盖升级
  B5 查询计划	用 EXPLAIN ANALYZE 在 5 万行/稀疏会话（20 条）上验证：OR 被展开为 idx_conversation 范围扫描 + 20 行排序（0.41 ms），新增的未读统计与回执查询走 idx_receiver_unread（0.03 ms）。结论：无需新增索引；UNION ALL 改写只快约 2 倍（微秒级），收益不足未采纳	无
  缓存链	assets/js/tab-card.js 的 IM_BUILD 由 20260929-5 递增为 20261002-1。assets/im-plugin/** 被 nginx 强缓存，不递增会导致老用户继续执行旧 JS	无
  新增文档	docs/聊天即时通信说明.md：传输模型、接口契约、已读回执、实测对照表、前端缓存注意事项、C 档（Go SSE 推送）规划	无
  依赖 / 扩展	无新增依赖；Go 服务未参与本次改造	无
  自检	线上实测（真实会话 + 真实 AJAX）：增量空轮询 128 B、无未读时 0 次 UPDATE、有未读时 +1、peer_read_id 端到端打通（发送 → 对方拉取 → 发送方看到已读 id）、消息按 id 升序；php -n -l 全部通过；node --check 覆盖 4 个 JS 与 messages.php 内联脚本（28 KB）全部通过	无

• v0.3.95

  巡检日报目录安全加固

  随交付包发布

  性质：安全修复。v0.3.94 的日报默认目录取自脚本所在目录，而脚本随包放在站点根 → 日报（含站点路径、数据库版本、告警明细）落在 Web 根内，实测 /reports/qdcms-report-.csv 可被公网直接下载（HTTP 200）。

  查看完整变更

  性质：安全修复。v0.3.94 的日报默认目录取自脚本所在目录，而脚本随包放在站点根 → 日报（含站点路径、数据库版本、告警明细）落在 Web 根内，实测 /reports/qdcms-report-*.csv 可被公网直接下载（HTTP 200）。

  类别	变更	升级动作
  安全修复	-Report 默认输出目录改为 C:\ProgramData\QDCMS\reports（Web 之外）；若 -ReportDir 指向任一站点目录内（或路径含 \\wwwroot\\），脚本追加 WARN 提示	覆盖升级即可
  纵深防御	/reports/ 纳入三处拒绝规则：nginx.conf.example（新增 location ^~ /reports/）、-CreateVhost 生成的 vhost 模板、qdcms-selfcheck.ps1 的敏感路径探测清单	已有站点按 docs/Windows部署说明.md 第 6 条补规则并重载 nginx（本站已补）
  文档同步	docs/Windows部署说明.md 8.3 节补充日报目录安全说明与 WARN 行为；第 6 条坑位清单加入 /reports/	无
  自检	修复后实测：/reports/qdcms-report-*.csv → 404；-Report 默认写入 C:\ProgramData\QDCMS\reports；自检新增 /reports/ 探测项通过	无

第 7 / 10 页 · 每页 10 条 · 共 93 条