平台功能（自研）
用户待办
用户待办是工作台「待办事项」卡片的数据来源，表为 sys_user_todo。它刻意做得比常规 CRUD 更窄：只服务当前登录用户自己的几条记录，没有管理端列表，也没有权限标识。
为什么没有权限标识
待办是「我自己的数据」。如果给它挂上 system:todo:list 之类的权限，普通用户会被挡在自己的待办之外；而如果要给每个用户单独授权，又不现实。
因此接口的边界不靠权限，而靠服务端过滤：
- 查询固定拼接
user_id = 当前登录用户； - 新增时
user_id由服务端写入，忽略前端传值； - 修改、删除前先
requireOwn(todoId)，不是自己的记录直接拒绝； - 登录态由全局 Sa-Token 拦截器保证，未登录请求返回 401。
字段
| 字段 | 说明 |
|---|---|
todo_id | 主键 |
user_id | 所属用户，服务端写入 |
tenant_id | 租户编号，随 TenantEntity 自动隔离 |
content | 待办内容，新增必填，最多 200 字 |
done_flag | 0 未完成 / 1 已完成 |
done_time | 完成时间，勾选完成时写入，取消完成时清空 |
sort_num | 显示顺序，默认 0 |
del_flag | 逻辑删除 |
表结构脚本在 script/sql/update/sys_user_todo.sql，使用 CREATE TABLE IF NOT EXISTS，可重复执行。
接口
| 方法 | 路径 | 说明 |
|---|---|---|
| GET | /system/todo/list?doneFlag= | 我的待办，doneFlag 可选 |
| POST | /system/todo | 新增 |
| PUT | /system/todo | 修改内容、勾选完成、调整排序 |
| DELETE | /system/todo/{todoId} | 删除 |
列表排序
固定按以下顺序返回，不提供自定义排序参数：
done_flag升序——未完成在前，已完成沉底；sort_num升序；create_time降序——同序号时新加的在前。
新增
只要求 content 非空（AddGroup）。服务端会强制：
todoId = null，避免前端指定主键；userId = LoginHelper.getUserId()；doneFlag = 0、doneTime = null；sortNum为空时填0。
修改
todoId 必填（EditGroup），content 可选——勾选完成时前端不需要把内容一起回传。
- 传了
content才更新内容； doneFlag只接受0/1，其他值抛「不支持的完成状态」；- 置为
1时写入doneTime，置回0时清空； - 传了
sortNum才更新排序。
删除
逻辑删除，同样先校验归属。删除后不会再出现在列表中，数据仍保留在表里。
前端用法
// 工作台初始化：拿全部待办
const todos = await get('/system/todo/list');
// 只看未完成
const open = await get('/system/todo/list', { doneFlag: '0' });
// 新增
await post('/system/todo', { content: '处理本周工单' });
// 勾选完成（不需要回传 content）
await put('/system/todo', { todoId: todo.todoId, doneFlag: '1' });使用边界
- 这是个人工具，不适合拿来做任务分派、审批流或团队协作；需要这些能力时请使用工作流或业务模块。
- 每个用户只能看到自己的数据，管理员也不能通过这组接口查看他人待办。
- 数据按租户隔离，切换租户后看到的是另一套待办。
- 没有批量接口，也不建议一次维护成百上千条——它是工作台卡片，不是任务管理系统。