忘了为啥换成 cfw 了，反正就是换成 cfw 了

lost ark ，不过没有国服，所以。。。

@loading #64
1. 华为的手机都是自家天线+信号系统吗？不懂，就是确认一下；
2. 视频彩铃并不是新鲜技术，也不是华为独家支持，我今天就用米 9 看到了顺丰的视频彩铃，先不说背不背锅，至少你也得确认他看到的是啥广告再说吧；

@chtcrack #61 光想后端逻辑没审需求吧，你说的技术基础是对的，如果说三个接口的展现分别在三个不同的地方或者都需要可以单独用来获取数据，你说的这种情况是有意义的，承载量的计算也没什么问题。
但是题主说的这里是一个界面同时需要这三份数据，那么你说的根本就是鬼扯，因为每个用户一进这个页面就是三个请求，刷新也是，那就不存在你说的问题，而且因为 http(s) 链接的特性，实际上还会消耗更多网络和服务器资源。
这里前端确实可以自行做聚合，难度也不高，虽然接口相互有依赖会延长请求时长降低总体请求的完成率，但是在当下的用户体验里可以做占位型展示，可以通过体验降低用户的失望。
不过所有从后端的角度说不应该分开的也完全是瞎说，总归是要根据业务需求实际处理，这个页面从题主目前的需求里看，属于可以前端聚合也可以后端聚合的情况，如果可以用到缓存的话其实更应该后端聚合。如果做后端真的只需要按表查询提供接口，那全都用 graphql 得了。

居然都支持这么多年了吗？我们还在用那个传统的 html 不缓存的套路。。。赶紧学习一下，让运维看看
它图里的源站指的是 aws 或者 netlify 自己的源站，所以文件变更就触发下次刷新基本上就和 edge 拉取 origin 的接口返回了不同的值一样简单，应该是在 edge 上部署了支持版本立即触发更新的逻辑，比如说在 edge 上都部署了支持版本管理的 sidecar ，通过接收 push （ pull 还是做不到“下一次更新”）的能力来支持下一次请求更新。

配合 OP 头像真的喜感拉满，我都笑出声了

@pdog18 #12 哈哈哈哈哈哈哈哈

1. 自己写一个 globalHook ，用来存取 ref
2. App 里获取到 ref 后在 effect 里存到 globalHook 里
3. 用的地方通过 globalHook 获取 ref

支持，postman 的 mock 确实有点儿呆，希望加强 mock 部分的能力。
另外我比较不爱用这些工具的原因是使用一次感觉很麻烦。一些小型的项目，小于 10 个接口，总工期可能也就 2-3 天，整一下这玩意就得半天，实在浪费时间，不如在代码里直接使用 mock 数据。不知道这种提高效率的能力有没有办法通过软件做到。

你就说你用的时候有没有觉得这个设计反人类吧。。。
我是每次都巨难受，因为如果要做商品比较的话几乎不可能，就逼着你看到了赶紧买。

使用三方服务，很多答案，推荐一个这个： https://github.com/localtunnel/localtunnel 基于 nodejs 的命令行工具，需要安装 nodejs 的运行环境

@shunia #14 再一个就是还是想要更有竞争力的客户端产品，目前的客户端似乎缺乏比较方便的自定义能力。我日常使用 cfw 都已经做到 mixin+parser 了，不用的时候觉得这些功能可能多余，需要用的时候还挺击中痛点的。

刚试了一下，0 配置我个人觉得真的挺好的，但是还是觉得服务器端有配置文件更好一点，方便需要重启的情况。
另外也希望客户端可以做到故障自动转移，因为日常使用过程中真的是经常遇到断线等情况，有时候甚至分不清是设备的网断了，还是服务不可达，就很难受。

Lark 是指飞书？邮箱没有出技术故障啊，是你自己的问题吧。。。

碰瓷式营销？拉黑了

@locoz #79 “晨会之类短周期的会议之所以不好”
首先效果并没有“不好”。
其次，从我个人实践的效果，和目前全公司推行后的效果来看，“不好”的原因基本都是晨会发起人的问题。我觉得晨会是一个非常好的实践。

晨会要成功，最关键的点是发起人能理解自己是在做管理。

另外晨会的客观功能性是要远远要强过管理工具 /聊天工具等方式的，而且不可替代：
强同步性和实时性能极大减小成员之间认知不一致的情况，有效降低沟通成本；
从精神上能树立一致的目标和理念，维持成员的活性；
以管理人员的视角，在晨会上快速确认任务执行所需的资源、遇到的阻碍、需要的跨部门协调，能保证任务跟踪的结果总是在进度之上；

简单来说其实就是能做到降本增效。

但是晨会有个问题是规模太小，或者团队对外依赖极低，那么效果就不会太好，因为本身就没有多少要追踪的事情；
晨会规模太大也不行，这个就不用多说明了吧；

我觉得很多人对晨会有误解是自己没有参与过高品质的晨会，也就是没有遇到过懂得执行晨会的领导。

市面上没有，如果你做出来了，轻松成为商业项目