@Curiosity777 我用的 whistle ，对前端开发比较友好。

前端吗？可以尝试将测试环境（甚至线上环境）的请求转发到本地 dev-server ，大部分项目都可以这么处理，甚至包括微前端。
本地 Mock 容易带来跟不上迭代的脏数据，长期不更新会出现破窗效应。

已注册：umaker

@PotatoYz 微信读书为啥是 6/月？

@NewMoorj 搜了下的确有这个，谢谢你让我这个大冤种更难受了😐

@XhivaW #14 你这么说好像也挺有道理的。感觉自己当时就是不太想花时间去研究和对比，想快点修好吧，也许年轻几岁还会有折腾的动力。
割的就是我这种韭菜。🤡

@limyel 毕竟才用 2 个月，还没存储太多内容，而且大部分重要文件都通过坚果云和 syncthing 保持了云同步。部分需要反激活的 App 没太注意，但是后来发现也有解，比如 Surge 可以在官网重置。

@pan020037 #10 很正常吧，我能理解自己的这种心理。人不会是完全理性的。

@mcczzz 没有。这个店好像没权限补？得去 Apple Store 吧？不太清除，也没有问。不过我想，即使可以，我应该也不会在刚花了这么大价钱的维修后，再继续买一个保险吧，即使从未来看这样更合理。

@hanierming 所以 AC+也就是只买 3 年的安全保证，虽然我想大多数人的 macbook 不会只用 3 年，肯定不是完美的，但在真的出现问题后，不仅在金钱上，也在心理上给自己兜了一定的底。
另外，我觉得自己不算特别粗心，上一个 mac 用了 7 年也没出啥问题，上帝视角上看就是概率问题。

@XhivaW 自己没有足够信任的渠道，担心给换了个水货屏幕

我认为关键在于你如何定义 dialog 的多于少。
如果一个页面或者整个项目里要使用的 dialog 数量（按类型计算）会以数量级的方式增加，比如这次需求有 2 个弹窗，下次需求就可能加到 20 个或者更多，这种情况，是需要考虑如何从项目顶层设计才能更好地承载这样的业务模式；
如果只是递增形式的变多，那只是业务需求而已，按照需求的描述，做好基本的代码管理就可以了。
什么是好代码？不要让维护者看不懂你的代码就是好代码。

1. 使用 slot 实现
2. 使用一个状态管理工具

为了做到不直接修改对象类型的 prop ，搞一堆 emit 和 watch ，我觉得挺闹心的。

感谢分享！
Y2hlbnpocS4yQGdtYWlsLmNvbQ==