更无语的是哪种不能说不熟，发个在吗，回了在，过半小时他又给你发了个在吗，然后就这么来来回回的折腾，感觉血压都升高了

@xiaocongcong 这种难道不是应该说，你好，现在是否有空，云云之类的，在吗这个其实更不礼貌了有没有😂😂

不 join 单表读有啥压力。。别过度优化啊，复杂查询大多也能接受延时，还是异步同步好吧

@vislins 矫情，迫害妄想症，好像苹果谷歌就不限区似的，没件事情都是有成本的，都是要考虑成本的，只有成本没有收益的事情谁愿意干啊，不影响他人谁 TM 想理你

工信部发的是政策要求，其实并没有任何技术实现要求，也不可能有技术实现要求，实现是各厂商自己怎么选择的事情，最终落实估计也就是不备案的不允许上应用商店的事情，这早 8 年的不就已经是这个样子了，一个事实标准变成一个政策要求，搞不懂大家为这事激动个啥

长期的话边际收益太低，工资涨 3 倍估计才能覆盖边际成本吧，但是对于公司来说，增加两天工作日产出增加估计都不到 20%，所以显然员工和公司都不合算，所以不接受，也没啥意义

高带宽内存，现在大火的，AI 也很需要

把常用的不需要代理的应用比如微信支付宝什么选按应用分流，其它的不怎么用其实就不怎么耗电了，按应用分流是安卓系统提供的功能，底层走的是策略路由表，所以性能和能耗是可以得到保证的，不用担心太耗电

304 不是未修改可以用缓存。然后浏览器就读缓存成功了，最后给你返回 200 没问题啊，毕竟已经有正确的内容了，是你理解的有问题吧

如果只是某中 pod 简单用下，倒是弄个 pod 配置里添加下 hosts 把需要出口的域名指向需要出口的地址，然后在需要出口的地址挂个端口转发程序 pod 就好了，如果有出口 node 端口占用的问题，那么还可以把 hosts 指向本机然后在当前 pod 再配置个容器再端口转发一次，这样出口 node 节点就可以使用其它端口了

当然如果大部分 pod 和大部分流量都需要转发那还是 route+nat 或是 istio egress 比较好

哥啊滴滴被罚已经是很久以前的事了，你这延迟有点高了，再说大佬都说过知错就改还是好同志，而且吧红绿灯倒计时也不是啥敏感数据，有啥不能开放的，也确实是个好事也可以为未来智驾做铺垫，管方确实在开放接口了

调用链最短化和代码复用最大化考虑实际情况取最优就可以，不要太纠结，有时一开始就想各种复用就是瞎搞，然后一层调一层各种子包子项目的，其实也是乱的一塌糊涂，最后一看毛复用的情况都没出现，纯属一开始瞎想

如果是微服务体系下，单项目应该尽量单一职责，服务规划合理的情况下，项目内本来就应该缩短调用链，再一层调一层其实很多余才是更坑死

@huangya #16 其实你只要理解硬件的中断优先级是手动管理的，硬件编程和软件编程不一样，如何调度何时调度都是固定的，所以每秒留给按钮处理程序多少时间一般就是提前设计好的，几乎不会有明显波动，所以一般来说就人的反应来说并不会出现来不及处理的情况，而且吧就算是嵌入式程序，设计合理严谨的程序也不会直接在中断里直接完成逻辑处理，一般都只是获取完状态然后创建任务交给主程序完成业务逻辑，那么这种情况下，每个中断的处理时间是完全精确到了具体的时钟周期，提前就可以完全精确的算出了每个中断耗时和冲突情况，既然如此按钮能否正常处理提前就能知道啊

而对于有操作系统的像树莓派这种，一般来说应用程序层面接收到的都是内核给的软中断，一般不是驱动程序的话并不能直接接收到硬件中断吧，否则岂不是应用程序处理异常就会导致内核直接崩溃，换句话说内核负责管理了中断优先级和调度延时，同样一般内核也能保证硬件中断能得到及时处理，毕竟硬件中断并不会受到系统负载的影响，而对于网卡、USB 之类需要处理大量数据的这种设备，其实硬件已经通过 DMA 把数据直接存到内存了，硬件中断只是告诉操作系统有新数据已经保存到内存，之后同样转有软中断处理，所以硬件中断所做的事情是非常少的，不能及时处理的可能性很小，软中断自然收到操作系统调度影响但是此时程序设计本身就能支持不确定延时了吧

@knockkey #4 既然食材按正常售价卖就可以，为啥要降价卖，你要知道你可不是大卖场，受限于食材加工等其他成本变化通过简单增加销售率大概率并不能提高收入，再说过路这事吧，8 成估计都是住附近或者在附近上班啥的，否则就纯过路，一般这种都不是出来闲逛的，就算恰好还没吃如何又有时间能来你店里吃顿饭呢，否则就没有餐厅如何选址选类型这个至关重要要命的问题了

而且如同其他楼说的，经营稳定的餐厅熟客的比率非常高，你这价格不确定你让他们如何决策今天要不要来你餐厅吃饭，再说就按你说的，来吃的人多了排队人多了你就涨价你确定人家不会立刻扭头就走？人少了就降价你确定正在吃饭的人不会掀桌子？而且吧要是之前来过你这的发现价格将了人家未必会开心但是要是发现价格涨了十之八九要扭头就走

你要知道餐饮给客人的不止是结果也是过程，你这闹心的又不是做的啥了不得的东西谁愿意来你这吃饭啊

生意好的店一直好，生意不好的一直不好，所以动态在哪了。。

而且食材员工都要提前购买招聘准备，无法动态变化，上座率不足的食材人员桌台都直接砍了，再说就算你觉得上座率不足临时降个价客人也不能立刻知道又恰好在附近又没吃放，所以你哪里看出来能动态定价了

如果是嵌入式程序的话你想多了，中断要么被屏蔽，触发了执行权就给你了，你的手不可能有这么快，而且大多数中断都是低到高或者高到低触发中断，如果恰好那一刻中断被屏蔽那就不会触发中断了，不存在调度逻辑，而且就算有防抖也不可能那么长，手按操作再快也要几百毫秒一次了，这时间对 cpu 来说可是非常长的

长时任务不要用暂时对接和计时器，否则就是个大坑，最靠谱最简单的还是每天执行个任务查询下满足条件的执行就好了