版本 1.0.0 更新：

• 会话聚合：把与同一聊天对象的私信自动归集成一条会话，私信不再散落在「通知」里。
• 完整往来记录：进入会话后按时间顺序查看你与对方的全部收发历史，并支持直接回复。
• 实时字数提示：输入框实时显示「字数太少 / 还可输入 N 个字 / 已达上限」，提交前前端拦截。
• 按用户组精细权限（后台设置）：

单条私信字符上限（超限禁止发送）
单条私信字符最小值（低于提示「字数太少」）
私信总量上限（达到上限自动清理最早旧私信，不阻断收发）
每日发送上限（达上限当日禁止再发）
发送一条扣除积分（余额不足禁止发送，0 为不扣）

• 全局默认 + 按组覆盖：每个维度先设全局默认值，再为指定用户组单独覆盖；组留空即继承全局，且覆盖优先级高于全局。
• 官方未读计数联动：复用官方 app_notifications，私信未读自动体现在官方徽标，标记已读时同步官方计数。
• 他人主页联动：将官方「私信TA」按钮指向本插件的私信会话，不改动核心代码。
• 安全与性能：登录/发言权限校验、CSRF 令牌、全参数化查询、单查询聚合 + 批量补数据（无 N+1）、发送副作用事务原子化。

本次复查确认正常。21 条 .ai-rules.md 规则全部满足，配置三处（常量/默认值/后台）与优先级逻辑完全自洽，查询均为单查询/批量 IN、无 N+1。

修修补补差不多4小时（30次+对话），我觉得下次更新收1积分应该不过分吧😀

私信对话ui改成，聊天app的对话界面更好😀

🔍 插件审查报告（对照《AI 开发规则》与开发者文档）

🔒 安全问题

未发现明显越权/SQLi/XSS/CSRF 问题。越权:会话/消息查询均严格限定当前 uid——mymsg_thread_messages(plugin.php:301) 用双向闭合条件、mymsg_threads(214)、mark_thread_read(317) 均含 $uid,peer_id 强转 int,无法读他人私信;profile_tab 系列均校验 self/$uid===viewer(362/364/376-377)。SQL 全部占位符,IN 用 sql_marks(193),唯一字符串插值 $peer_expr 内 $uid 为 int 类型参数(207/249),不可注入。XSS:正文经 markdown_html(497),预览 strip_tags 后再 h()(450),用户名/徽标均 h()。CSRF:发送 require_post(530)+全局 check(),表单 form_token(505),后台 require_post(836)+form_token(932),后台入口由核心 need_admin() 兜底。

⚡ 性能问题

无明显循环查询:threads 一次 GROUP BY 聚合 + 两次批量 rows_by_ids(223-224),符合「先收集 ID 再 IN」规范。轻微:通知 Tab 在数据加载 hook 内执行 COUNT+全量 UPDATE 标记已读(391/411/419),翻页会重复写。

🐛 功能/规范缺陷

1. (严重)mymsg_js() 内 $tab_base = route_url('user',['id'=>uid(),...])(plugin.php:677) 依赖当前用户,违反规则 114(资源函数不得依赖当前用户/请求);而 assets 在构建时一次性写死进 plugins.js,uid() 固化为构建时值,导致所有用户的「私信TA」重写(686-700)指向错误 uid 而失效。应改由页面 HTML 的 data-* 注入基址。
2. mymsg_trim_total(181-195) 删除 recipient_id=? OR sender_id=? 的双方共享行:清「自己」旧私信会连带删除对方会话历史;且删除含 read_at=0 的行后未同步重算双方 unread_notifications,计数漂移(偏高)。
3. kind 与前提不符:MYMSG_KIND='direct'(21) 复用核心 user_notify_page 的 kind(index.php:2356)。核心 /notify 路由仍可直接发 kind='direct' 且无字数/每日/积分限制,插件配额可被绕过。
4. post('content',$conf['max_len']) 已截断(553),故 559 行「过长」报错永不触发,超长被静默截断而非拒绝;且先 create_notification 后扣分(575/578),扣分失败私信已发。
5. description(972) 含「用户组/积分」等技术词,略超「面向普通用户」要求;author='one' 简略。

✅ 修复优先级

P0:缺陷 1(JS 依赖 uid 固化,改 data-* 注入);缺陷 2(trim 改为只清「我方收到」或同步重算双方未读计数)。P1:缺陷 3(配额绕过——需禁用/改造核心 notify 入口,或换独立 kind)。P2:缺陷 4(先验长度再截断/先扣分或事务化)、5。

版本 1.0.2 更新：

最严格全量审查报告 —— mymsg 私信插件

对照基准：.ai-rules.md（21 条 + 描述规则 22）、开发者文档.md、核心 index.php 实际实现。

安全性（核心结论：无阻断级漏洞）

• 越权：所有消息查询（mymsg_threads/mymsg_thread_messages/mark_thread_read）均强约束 recipient_id=$uid OR sender_id=$uid 且 peer 强转 int；profile 系列校验 is_owner/$uid===viewer。无读他人私信路径。✅
• SQL 注入：全部参数化；IN 用 sql_marks()（193 行）；唯一拼接 $peer_expr = recipient_id+sender_id-? 中 ? 为 int 参数（207/249）。无注入面。✅
• XSS：正文 markdown_html（497），预览 strip_tags+h（450），用户名/徽标均 h，头像走官方 avatar_tag。✅
• CSRF（已厘清，非缺陷）：require_post() 仅校验请求方法；真正校验在核心 check_csrf()（index.php:1480-1488）全局层对所有 POST 比对 $_POST['_csrf']，表单 form_token() 输出该域。发送/后台均含 token，防护完整。✅（此前报告称「require_post+全局 check」准确，无遗漏。）
• 危险行为：全文无 exec/eval/system/shell_exec。✅
• 事务：发送路由无外层 tx()（已修嵌套事务），副作用顺序 create_notification → user_points_change（自带 tx），余额已预检，无半截数据风险。✅

性能（核心结论：单查询、无 N+1）

• 会话列表：1× GROUP BY 聚合 + 2× rows_by_ids 批量 IN（用户资料+末条消息）= 3 查询，零循环内查询。✅
• 会话详情：1× 查询 + 1× COUNT + 1× UPDATE，无 N+1。✅
• trim/计数：聚合 COUNT + 批量 DELETE，无循环。✅
• 已验证无「hook 挂错」误判：topic.index_data.load（index.php:2679）确以 ctx['profile_tab'] 承载 profile tab 数据加载，故 mymsg_index_data_load 在通知 Tab 渲染时正确触发并剔除私信。✅

未读计数一致性（核心结论：双机制无漂移）

• create_notification（index.php:934）发私信后接收方 unread_notifications+1；插件 mymsg_sync_unread_counter 以 COUNT(read_at=0) 实查重算兜底（trim/标记已读场景）。两机制目标值一致，重算覆盖 +=1，无偏高/偏低漂移。✅
• 发送路由依赖 create_notification 的 +1 更新接收方，未遗漏 sync（设计正确）。✅
• mymsg_mark_thread_read 仅标记「对方发给我」未读；mymsg_mark_others_read 仅标记「非私信」官方通知；二者互不串扰，且与 mymsg_index_data_load 进入通知页即标记他人通知已读语义一致。✅

规则逐条对照（21 条 + 22）

1. 最小可行/复用官方 API ✅　2. 最小权限/登录校验 ✅（need_speak 含 need_login）　3. 无危险行为 ✅　4. 异常安全/SQL 防护 ✅（占位符统一、无嵌套事务）　5. 错误可操作 ✅　6. 中文界面 ✅　7. 输入校验 ✅（前后端双校验一致）　8. 单查询/无 N+1 ✅　9. 数据一致性 ✅（未读实查重算+事务原子）　10. XSS ✅　11. CSRF ✅（全局层校验）　12. 前端资源 ✅（内联、无外链）　13. 官方样式复用 ✅（CSS 变量一致）　14. 可配置 ✅（全走 plugin_config+组覆盖）　15. 发送方可见已发送 ✅（UNION 双口径+自身无未读通知）　16. 防重复提交 ✅（disabled+reload）　17. 结构化错误 ✅（err 结构 + JS 读 message）　18. 无 console 残留 ✅　19. 移动端适配 ✅　20. 可维护/注释 ✅　21. 兼容官方数据模型 ✅（复用 app_notifications 零新增表）

结论

无阻断级（P0/严重）缺陷。缺陷经验证均已正确修复；本轮新增核查推翻了「hook 挂错」的潜在误判（已证实钩子正确生效）；未读计数双机制、CSRF 全局校验、事务原子性均经核心代码交叉验证为一致。

感谢 @350 检查

🔍 插件审查报告（AI 自动审查，对照《AI 开发规则》与开发者文档；本插件未被 8/18 楼上 350 的报告覆盖，属独立首次审查）

插件：我的私信（mymsg）v1.0.2

🔒 安全问题
未发现明显安全问题。

⚡ 性能问题
未发现明显问题。

🐛 功能/规范缺陷
规范一致性建议：后台管理页函数体内未见显式调用核心 need_admin()（依赖核心 admin_page() 路由层统一鉴权兜底，当前不构成越权）；涉及写操作时判断请求方式使用手写的 $_SERVER['REQUEST_METHOD'] === 'POST'，效果等价于核心 require_post()，但写法与站内多数插件不一致。

✅ 修复优先级
低优先级：建议在后台页面函数内补充显式 need_admin()/require_post() 调用，作为纵深防御，避免未来核心路由调整时失去这层保护；不影响当前功能与安全性。

版本 1.1.2 更新：

• 删除死属性 data-override="1"（无 CSS/JS 消费者，样式已由 mymsg-gi-override class 承担；且裸 data-override 违反 data-* 前缀规范）
• mymsg_sync_unread_counter 的 __me_cache 失效（L349-351）：已有 array_key_exists 守卫 + 注释，单点位，合规

余额预检 → 发通知 → 扣分的竞态窗口：此前与您讨论定型的设计（预检紧邻，窗口毫秒级；pm 启用时整段跳过由 pm 事务化扣费），保持不变

• JS 用 notify-link class 定位：核心尚未为该按钮提供 data-slot 插槽，class 是当前唯一可靠锚点；若未来核心给它挂 slot 可再跟进