@Saxton #25 每一种业务有不同的表，对吧？现在要把所有业务的待办列到一个待办列表里，中间必然有一个步骤是查询多种业务表，然后生成待办。可以选择在客户点开待办的时候去查，也可以先在后台查好在推送到前端。

@Saxton #22 归根结底待办是业务逻辑的延申，随业务逻辑的变更而变。
如果一开始业务逻辑就抽象了业务和待办的关系--比如用工作流引擎和事务来封装业务逻辑，
那么待办逻辑也可以聚焦起来。
现在在屎山里面抽丝剥茧新增待办逻辑确实很难优雅。

@libook #21 我感觉优化很难，因为一个用户可能有数十种待办，每种待办意味着一套独立的查询。针对每个查询可以优化，但是投入和产出不成正比。

我怀疑是妹子身上的味道不行，比如酒味太重。
如果有龙涎香的味道，不信硬不起来。

@Saxton #15 也算产品吧。

@Saxton #17 你说的这个方法就不是点击时主动查询了，实际上是后台查出来后更新到一个待办表，问题在于待办表什么时候插入记录？这里有两个选择：一是定时轮询，好处是可以外挂逻辑，不用侵入到业务代码。缺点是要为每个人的每种待办查询，速度是个问题 i ；
二是在业务逻辑中判断并插入到待办，缺点是侵入了业务代码，要改的地方很多很分散。。。

@nothingistrue #14 确实也是从消息导航到处理界面。重点还是第一个问题，每次即时查询待办太慢，所以才想是否可以用通知代替即时查询。。。

@nothingistrue #12 问题在于主动查询太慢了，有些岗位十多二十个待办种类，每一个都即时查询很花时间。

@Saxton #10 意思是看通知，待办数量是 1 ，点进去看待办数量是 0 ？（因为已经后台监控修改了待办状态）

喝醉的妹子，还能帮你找位置？到底谁喝醉了。。。

@Saxton #7 明白了，就是跟触发通知一样的逻辑，后台监控发现完成了就消除通知？

@gainsurier #5 ？？

@Saxton #2 似乎你的方法也只能手动点击完成待办，对吧？

@Saxton #1 有的待办有明确归属人，有的待办可以有多个人可以处理。

我 148 是资深用户专享价吗

OP 你截图这个界面怎么调出来的？

由 OP 的需求想到 NS 的下一代方案：
主体集成在手柄里，中间夹一个可更换的屏幕，屏幕有多种大小可选。