QQ扫一扫联系
用户报问题，最常走的路是加客服微信。图片、日志、账号信息全在聊天窗口里散着，三天后要找「上周那个说登录不上的用户」，得往上一屏一屏翻。
工单反馈把这条路换成一张单据：前台提交，系统给一个编号，后台回复，来回都有记录。
前台 /feedback_ticket 是一张表单：标题、内容、邮箱、微信、QQ，附件可选。
联系方式有三栏，不是让你全填，是让用户挑一个能联系上的。很多人没有 QQ，也有些人不用邮箱，把三种都放出来，回复率会明显高一些。
提交成功后页面给一个工单编号，16 位大写字母数字。这个编号是查进度的唯一凭据：/feedback_ticket/{编号} 打开就是这条工单的往来记录，不需要登录。
这个设计对「还没注册的用户」特别友好。装了会员的站可以不要求登录就报问题，代价是任何人拿到编号都能看这条工单——编号是随机 16 位，猜不出来，但如果用户把截图发到群里，别人也能打开。
后台的「工单反馈记录」列表：工单编号、名称、邮箱、微信、QQ、内容、状态。
工单由前台产生，后台负责查看和回复，列表上没有编辑动作。这是对的：工单是用户提交的原始描述，改了就失去证据价值。
列表可以按编号、标题、状态筛。用户来问「我的工单处理得怎么样了」，按编号一搜就到。
| 状态 | 含义 |
|---|---|
| 处理中 | 有人接手了，正在处理 |
| 等待回复 | 回复发出去了，等用户补充信息 |
| 已关闭 | 处理完，正常关闭 |
| 已关闭（过期） | 太久没动静，系统或人工关掉 |
| 已关闭（用户） | 用户自己关的 |
这个状态机不复杂，但要养成改状态的习惯。全是「处理中」的列表，等于没有状态。
回复的时候会给用户填的邮箱发一封通知，里面带工单编号和回复内容，用户点链接回到工单页继续对话。
发信走的是队列任务（MailSendJob），不是同步发。这个选择很关键：SMTP 有时会卡十几秒，同步发会让后台的「回复」按钮转很久。走队列之后，点完立刻返回，邮件在后台慢慢发。
代价是队列必须有人跑。站点的消息队列没配或者没启动，表现是「回复成功了但用户没收到邮件」，日志里能看到任务堆积。部署时把队列进程的守护配上。
另外，邮件服务器的配置在站点的基础设置里，不在这个模块。SPF、DKIM 这些没配好，邮件会进垃圾箱，用户以为你没回。
提交和回复都能传附件，附件存在站点统一存储里，走 /feedback_ticket/{编号}/file/{回复ID}_{序号} 这个地址下载，真实路径不暴露。
这里有个容易忽略的清理动作：删除一条工单时，模块会把它下面所有回复的附件文件一起删掉（deleteReplyFiles），再删回复记录。也就是说删工单是不可恢复的，附件也跟着没。想留档就先导出。
技术支持入口。用户报 bug、报故障，附带截图和日志，比微信强得多。
售前咨询分流。有些问题不适合在即时聊天里答（需要查订单、需要技术确认），转成工单更清楚。
内部 IT 报修。员工电脑坏了提一张单，IT 按单处理，月底能统计出「哪类问题最多」。
不适合：需要秒回的咨询。工单的节奏是按天算的，用户预期也是「一两天内有回复」。要即时，用在线客服那个模块。
