@shyrock 其实不用在这纠结这个 01 问题，这个是产品该纠结的问题，产品如果需要那肯定就是需要，除非你就是产品。

@shyrock 像你所说的，一条待办可以很多人处理，那就肯定会下发通知给多个人， 其中一个人完成其他人的通知还存在，这个行为很正常，你想想，一个人收到一条待办消息，暂时没空处理，另外一个人正好有空给他处理了，但第一个人要处理的时候发现通知怎么没了， 就很奇怪了，正常的逻辑是第一个人想要处理点通知进去发现已经被处理了就不处理了，这个逻辑很正常，但有些产品设计时会考虑到用户对通知的反感度， 太多的消息反而都不用处理就会引起用户的不满，就看产品怎么说了。

@shyrock 是的 不能说消除通知吧 ，通知这个东西一旦下发下去， 什么状态就什么状态， 而且通知一旦下发下去，你去手动消除他反而更不符合业务需求，用户明明收到他通知了，但被你删了，等到他看却发现没有，这个行为就很奇怪了。
待办会被变更为已完成。

@shyrock

手动点击完成待办？ 我们没有这个需求， 所有待办自动完成的， 触发规则就完成他， 比如 小明今天新增了一个合同信息，但合同还没签约， 这个时候就会新增一条合同签约待办给小明， 但如果当合同的状态变更为签约， 这个待办自动完成。 我设计的规则模板可以指定待办触发条件和完成条件

但我这个解析 binlog 的方式也有一定局限，在操作上有一定受限，毕竟是完全解耦独立的， 无法参与到业务逻辑中， 就看你需求了。

第一个方案有问，为什么要根据这个人各项属性查询数据？难道生成的这条待办没有归属人吗，还是说大家都可以处理掉这个待办
第二个方案也有问，"缺点是在其他终端处理了事项时没有办法消除所有终端的通知" ， 这个不是很正常吗， 通知这个东西一旦下发就很难做撤回的操作了。

待办事项的推送这块我也做过，不过场景没楼主这么复杂，都是一定条件后会触发一条系统内的消息和系统外的消息推送，条件的监控是监听数据库的 binlog 日志来做的，完全解耦并独立于系统外的，我的设计方式是设计好一套规则，如果监听到的数据行为符合这个规则就生成一条待办并完成推送，规则这块我设计了一个规则模板引擎，让运营在后台自己设置。

@ecloud 那项目经验那块怎么写呢？ 都一起写上吗还是，我特意去问了 HR ，他说遇到这种拿捏不定的简历一般直接过滤掉，招人很明确，要的就是这个岗位，当然可能每个公司情况都不一样。

？ 一份简历通杀所有岗位？ 我好奇你的简历是什么样的，可以大概看下吗

@yaott2020 好家伙。。。 买云电脑就是为了至极的真实本地体验，那这样子还不如买台 VPS 来得强。

微软已经被咖喱人攻占了，现在设计出来的东西一股咖喱味

@testcaoy7 我是建议买针对中国大陆线路优化的，这东西本身对网络非常敏感，我看官网也没有针对中国大陆的优化，“有海外业务需要”，那我更推荐你阿里云了，他的云电脑已经有海外线路了，而且是针对大陆优化的线路，我是建议你可以体验试试，新客户可以免费体验，我之前体验过了自我感觉还行。

就看有没有开通中国大陆业务了，如果没有那线路肯定都在海外，可以把你卡出翔，我刚看了下好像并没有对中国大陆的业务，国内做云电脑的挺多的，目前阿里云也在做，有免费体验也可以试试水。

ide 装个插件就行了

@Buges 是啊，宝塔这次就是冤大头了，还有看看 gitee 的，全是活生生的例子，开发者只提供工具给用户不负责任这个规矩在国内是行不通 的，毕竟中国是是连带责任，一个人犯错他背后的人全都得遭罪， 就像基层犯错领导被罚一样

@rekulas 剧本从一开始就是这样了，当发展起来了人的思想慢慢就打开了，很多人就会不同的想法了，肯定就要做一些对应措施了，我们是什么性质的社会，必须是同一个步伐向前的不允许有其他人跑到其他赛道的连着筋的， 这个性质就摆在这没办法，毕竟人多不好管嘛，那就只能多装几个监控了

参考 gitee

@Buges 主要是宝塔在里面加了太多自己的东西了，搞得搭建这个面板的服务器好像是他在管理一样，然后就被制裁了，笑死，直接从源头上下手，不过老哥说的也对，如果按照这个思路下去的话：
jetbrains 一开始他们还没强推账号体系，但现在新版慢慢在强化账号体系了，假设 jetbrains 是国内的厂家，那我们每一次编译的时候是不是也要把代码传到后台让人工审核，还得搞一个版本控制，编译发布版必须云编译人工审核才放包，想想就有趣。（ doge

aaPanel 你值得拥有