我就是因为没有同步功能所以用谷歌的，绑定时自己把绑定用的二维码（其实就是个 uri ）离线备份就行

@a62527776a next 仍然多余

提供这样一个不上不下的功能没啥意思，不如给用户完全控制框里的渲染和逻辑的方式
随便说几个场景吧：
a)取消也要异步 block 住
b)block 过程中用户希望在按钮上显示菊花 /其他文字
c)block 过程中用户希望改变框内主体的展示，变灰加字进度条都有可能需要
d)失败场景可能的需求有：框仍然消失 /框消失并通知外部改变状态 /框保留按钮变回可点 /框保留按钮状态改变 /弹第二个 alert 框告知用户失败并组合上述任意交互等等
不管你的默认行为怎么写，总会有其他需求，诱惑你再加更多 option 和 callback
问题的根源可能在于你没想清楚自己的组件的边界在哪里。我能猜到加这个 wait 的机制能满足你多数的需求，提高你的效率，但放到开源组件里，这个选项满足别人一半的需求，逼迫别人要么魔改 hack 要么不用，就是“不好用”的组件了

总体还行，挑些毛病的话：

已经 promise 和 async await 都上了还用 wait 这样的回调参数来做“后续干啥”，甚至这个回调参数里还有个 next callback 看着难受

活动页弹个窗这种小事还带上 vue 难受

有根葱，想吃火锅

产品要插手技术（架构）设计甚至是实现，相当于兼职架构师，你可以把他当架构师来问，问不倒的话就真的按他说的做就是了

基本不认同楼主所有观点，从第一句（技术人员多数喜欢技术？ 极少数才是）到最后一句（怜悯能力卑微的领导？ 怜悯什么是能力都不清楚的自己吧）

他说的都对，我们都是新一代的纺织工，都只是等着被淘汰，只有他才是新世界的救世主

@honmaple 不一定是技术上的问题，也可能是你在面试 offer 入职的过程要对下家的技术水平没有做好一个基本的把握，也可能是你其他方面的一些缺陷导致你无法拿到更适合你的技术水平的公司的 offer

关于技术上的问题，你可以和负责人沟通，提意见，如果他的回复中有东西让你学到你就好好学，如果你认为这方面难以沟通无法理解，那就默默按他的套路来做事，出了问题他是负责人，让他来组织怎么解决就行（说不定他就能比你更轻松的搞定呢，谦虚点跟着学咯）。当然，同时可以在外面看新的机会，但前提是你得想明白，真的就是公司不行负责人不行，你的问题真的是不会挑公司，否则问题大概率循环出现

说架构的话题的话，架构的大多数问题都是权衡和资源分配，没有免费的午餐，扩展性是要用初期开发速度，团队人员能力，上手难度等等来换的。如果给我一堆低水平的开发让我带又禁止我换人，那我就会考虑教会他们怎么在一个良好（而不简单）的架构下写扩展性好容易长期维护的代码合算，还是快糙猛简单直接的结构，就靠人工测试，不断重新堆积面条代码来实现需求，也许反而更合算。这种时候我设计架构的目标就是不看扩展性，只追求低耦合，确保任何一坨面条坏了都尽量少影响其他面条，能更便宜地堆人力上去重写

@hantsy ？这和平庸还是优秀有什么关系，我的观点是责任和权力对等啊

负责人平庸，那是老板的问题，最后输出不佳也是老板拿钱兜着，楼主觉得自己优秀所以受气，那还是自己面试入职考虑不周

负责人优秀，楼主无法理解和沟通导致误解，那还是楼主的问题，尤其是连续两次说明不是偶然，所以我很赞成让楼主自己反思问题在哪里

我只说楼主是因为这里只有一方的观点，在这里评价负责人或者公司既做不到客观又产生不了价值和意义，评论楼主则有可能让他变得更好，不是吗？

你知道负责人的责是什么责吗？ 他负责他就有权利对你提要求，你只能提意见，觉得无法接受就走人，并且像楼上说的一下反思一下自己为什么连续两家公司碰到类似的问题

这是 XY 问题
你应该解决的是标准化本地开发环境或者是 CI/CD 的问题，他们和版本控制有关但不是版本控制能够解决的问题

如果你觉得需要这些技巧是因为贵司不是靠产出而是靠看屏幕抓包网络在评估技术人员的工作绩效，我建议可以试试寻求更好的工作机会

这同时也是为了逆向淘汰不称职的管理层，净化行业环境做出的小小的努力，功德无量

@crclz 如果你觉得写代码无法做到完全避免并发冲突，那数据库代码是怎么写出来的？

不同项目的需求又不一样，我不认为这个问题有唯一正确答案，我按照楼主的标题提出了一个弊端而已

问题确实都有解决的方法，你说的数据转换层也许可以解决某些问题，但为此增加的成本和风险仍然是“弊端”，仍然需要考量如果只为了这么个事情引入一层架构是否合算。而且如果问题在于整个系统的假设（比如工号唯一）蔓延到多个模块以后被打破，可不是什么抽一层数据访问就能解决的

https://en.wikipedia.org/wiki/Futures_and_promises

> The terms future, promise, delay, and deferred are often used interchangeably, although some differences in usage between future and promise are treated below. Specifically, when usage is distinguished, a future is a read-only placeholder view of a variable, while a promise is a writable, single assignment container which sets the value of the future. Notably, a future may be defined without specifying which specific promise will set its value, and different possible promises may set the value of a given future, though this can be done only once for a given future. In other cases a future and a promise are created together and associated with each other: the future is the value, the promise is the function that sets the value – essentially the return value (future) of an asynchronous function (promise). Setting the value of a future is also called resolving, fulfilling, or binding it.

区分使用的时候，他们也是表示同一个模式的两个不同的部分，不存在两种不同的模型

@tubimasky 离职 2 次呢，至少 MySQL 肯定没有 partial unique index 这么高级的

数据库做唯一的一个风险是跟不上业务，想改回代码里处理的时候有点儿蛋疼

就比如说你举的例子就很经典，员工工号似乎是唯一的，甚至能当主键，但比如明天的业务需求就可能变成：离职员工回归后新开账号（原有数据不继承）但工号仍使用原来的工号

如果你仍然坚持用数据库的唯一来处理工号，就得改全部有关联数据的地方增加重新入职的清理逻辑，可是很多数据甚至是不能清理的，一地鸡毛。如果是代码里的逻辑，直接再插一条数据完事儿，原来的唯一检查改成入职状态下工号唯一就行了

那么比起先发出去再复制，发之前全选复制是不是效率更高呢？文本框可以直接 ctrl+a,c