项目评审会议记录 (Project Review Meeting Minutes)

日期: 2025年12月1日 参与人: 产品经理 (PM), 后端开发 (Backend), 测试工程师 (QA) 主题: 现有功能评审与迭代建议

1. 产品经理 (PM) 评审

观点: 核心功能闭环已完成，但用户体验 (UX) 细节有待打磨。

UI/交互体验:
- 语音交互: 目前“上滑取消”的阈值是固定的 (diff > 100)，用户没有视觉反馈。建议增加一个“松开手指取消发送”的视觉提示区域（类似微信的红色区域），让用户明确知道现在的状态是“录音中”还是“即将取消”。
- 消息类型: 界面上有 qsendText (Type 1) 和 gsendText (Type 2) 两种发送逻辑，对应“私有”和“全局”。这对用户来说可能比较晦涩。建议在 UI 上明确区分，例如使用不同的按钮颜色或图标，或者通过 Tab 切换当前发送模式，而不是并列两个按钮（如果目前是并列的话）。
- 加载状态: 下拉刷新时的 pullText 变化（“下拉刷新” -> “释放立即刷新”）是好的，但建议增加更平滑的动画过渡。
业务逻辑:
- 位置信息: 每次发送消息都强制获取位置 (wx.getLocation)。如果用户在室内 GPS 信号弱，会导致发送延迟或失败吗？
  - 建议: 位置获取改为异步或非阻塞，或者允许用户在设置中关闭“发送位置”功能，除非这是核心考勤业务必须的。

观点: 代码结构尚可，但配置管理和数据一致性存在风险。

配置管理:
- 硬编码 URL: API 地址 https://wx-xcx-check.blv-oa.com:4433 直接写死在 chat.js 中。
  - 风险: 切换测试/生产环境非常麻烦。
  - 建议: 提取到单独的 config.js 文件中，根据 wx.getAccountInfoSync().miniProgram.envVersion 自动切换环境。
数据一致性与分页:
- 分页逻辑脆弱: 前端计算页码的逻辑是 Math.floor(oldli.length / 20) + 1。
  - 风险: 如果在用户浏览期间，有新消息产生（或者删除了消息），基于数量的分页会导致数据重复或遗漏。
  - 建议: 建议改为基于 last_id (游标分页) 或时间戳分页，这样更稳定。
- 时间格式化: 前端自己处理 formatTime 并替换 T 为空格。建议后端直接返回标准格式，或者前端使用 dayjs 等库统一处理，避免手动字符串操作带来的潜在 Bug。
网络层:
- 乐观更新风险: qsendText 中先 pushMsg (渲染) 再 upload (上传)。
  - 风险: 如果 upload 失败（断网、服务器错误），用户界面上显示消息已发送，但实际上服务器没收到。
  - 建议: 消息对象应增加 status 字段 (sending, success, failed)。发送失败应显示红色感叹号，并支持点击重发。

观点: 异常处理覆盖不足，存在边界情况 Bug。

语音功能边界测试:
- 中断测试: 在录音过程中，如果接到来电、闹钟响铃或切出小程序，manager.onStop 是否会正常触发？目前 onUnload 做了停止，但 onHide (切后台) 似乎没有处理，可能导致后台继续录音或状态卡死。
- 短语音: 代码中 cost < 350 毫秒会被丢弃。这个阈值是否合理？用户快速点击可能会被误判为录音失败。建议给用户一个 "说话时间太短" 的 Toast 提示（目前代码里有 onError 处理 -30003，但手动停止的逻辑里直接 return 了，没有提示）。
权限流程:
- 拒绝后重试: authorize.js 封装得不错。但如果用户在系统层面（手机设置）关闭了微信的麦克风权限，wx.authorize 会直接失败。需要确保 fail 回调里的引导文案足够清晰。
兼容性:
- 屏幕适配: GetmyScrollhight 使用了 boundingClientRect。在不同机型（特别是带刘海屏/灵动岛的 iPhone）上，底部安全区 (safe-area-inset-bottom) 是否处理得当？建议检查 CSS 中是否有 padding-bottom: env(safe-area-inset-bottom)。