如何利用ThinkPHP构建企业级工单管理系统【实战】-ThinkPHP-PHP中文网

thinkphp虽不提供工单系统，但可通过合理模型设计、状态机控制和权限隔离快速搭建最小可用闭环：主表t_ticket仅存生命周期字段，关联表分存内容与日志；状态流转须经ticketstatusservice校验；rbac按操作粒度配置权限并做数据级校验；附件上传对接云存储并确保删库同步删文件。

如何利用thinkphp构建企业级工单管理系统【实战】

ThinkPHP 本身不提供工单系统，但能快速搭出可用的最小闭环——关键在模型设计、状态机控制和权限隔离，而不是堆功能。

工单不是简单的一张 t_ticket 表。硬塞字段会很快失控，必须拆成主表 + 关联表：

t_ticket：只存生命周期字段（status、creator_id、assignee_id、updated_at），status 用整型（1=待处理,2=处理中,3=已解决,4=已关闭），别用字符串枚举
t_ticket_content：存标题、描述、附件路径（JSON数组）、图片 URL 列表——避免主表 bloated
t_ticket_log：每次状态变更、评论、指派都写一条日志，含 operator_id、action（"assign"/"resolve"/"comment"）、before_status/after_status

TP6 的 hasMany 和 belongsTo 要配好关联，但别在控制器里用 with 一次性加载全部日志——查列表页时只取最新 3 条，详情页再查全量。

用户提交 status=3 并不意味着能直接“解决”，必须校验当前状态是否允许跳转。ThinkPHP 没内置状态机，得自己写：

定义一个 TicketStatusService 类，方法 canTransition($from, $to) 返回布尔值，比如从 1 可到 2 或 4，但从 3 只能到 4
所有更新 status 的地方（包括后台管理、API、定时任务）都必须调用该服务，禁止直接 $ticket->status = 3
在 TicketModel 的 beforeWrite 钩子中做二次校验，防止漏掉某处绕过服务层

否则会出现“用户把已关闭工单又改成待处理”这种逻辑漏洞，审计时直接被毙。

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

ThinkPHP 的 think-auth 扩展够用，但默认角色权限太粗——客服能看全部工单，但只能改自己创建的；技术组能改任意工单状态，但不能删日志。得这样配：

权限项用 ticket:assign、ticket:resolve、ticket:close 这种动词+资源格式，不用 ticket_edit
给客服组分配 ticket:view:own 和 ticket:comment:own，技术组加 ticket:view:all 和 ticket:assign
控制器里用 $this->auth->check('ticket:resolve', $uid) 校验，且传入工单 ID 做数据级校验（比如 ticket:resolve 要检查当前用户是否是处理人或管理员）

漏掉数据级校验，就等于把工单 ID 放在 URL 里任人篡改，/ticket/123/resolve 可能被改成 /ticket/456/resolve。

本地存储在企业环境里是定时炸弹：磁盘爆满、备份困难、CDN 不友好。ThinkPHP 的 Filesystem 驱动支持 S3 兼容对象存储：

配置 filesystems.disks.qiniu，用 qiniu/qiniu-php-sdk 扩展包
上传时生成唯一 key："ticket/{$ticketId}/".md5_file($file)."_{$file->getOriginalName()}"，避免同名覆盖
数据库只存相对路径（如 ticket/123/abc123_filename.pdf），前端拼 CDN 域名，别存完整 URL

附件删除必须同步删云存储文件，TP 的 deleteFile 方法要配合钩子，在 TicketModel::afterDelete 里触发，否则产生脏数据。