页面引用都是绝对地址 nginx 好像也有自动替换的功能，好像是 content_filter 之类的吧，但是静态资源又可能再有引用啊，还有 ajax 之类的咋办，所以最好改成子域名了，实在不行，或者看看能不能读一下 refer 匹配一下然后做 rewrite

组件模板作用域和 App 作用域不一样，你看 App mount 到了你写的 html 节点上，所以这个 html 是 App 作用域的，todos 却是属于 ListRendering 作用域的当然访问不到了，你要写组件模板才可以访问到的

别用过去眼光看未来，IDC 不用锂大概率因为成本问题，毕竟地又不缺，用铅酸电池不就多占点地方么，无所谓，此外小部分应该是安全问题，毕竟锂电池容易起火，热控管理还是挺难的，什么回不回收的谈环保纯属扯淡

再说回不回收这个问题完全和成本有关，去年初碳酸锂才几万块一吨，现在已经 30 多万一吨了，而且看这样子锂价还要涨，就算原来回收不划算，现在估计都要抢着来了，而且原来锂电池主要用在电子产品的小件，未来更大的使用量是汽车大件，投入不可同日而语，回收这种不是啥问题

@sogwsc 所以就不要想逻辑，想逻辑这剧就是毫无逻辑可言，主要是场景太简单了，完全就是小学一加一强行要演出高等数学的感觉，但是演技还行吧，也挺好看的

@crystale #3 这个 blocked 就是进程主动放弃运行状态进入等待的意思啊，cpu 指令执行是无法被阻塞或暂停的，单片机这样的系统会使用空指令死循环来占着时间等待 io 完成，windows 和 Linux 这种有操作系统的自然触发调度器切换进程了，如果没有任何进程可调度，那么此时 cpu 会有 idle 进程来执行死循环占着 cpu 时间，你用任务管理器看就能看到 idle 进程了

断开了自然没法给客户端发信息了，没必要怀疑这种违反物理规则的事情

没懂你在纠结啥，定时器是硬中断，到时间就会切换当前进程到等待调度，io 操作需等待的和临界区信号需等待的都是主动放弃时间进入等待状态，状态达成会重新进去等待调度，之后谁可以运行就看谁在前面谁优先级高了，中间又没有时间间隔

可以 md5 下两边模型看看是不是同一个，说不定模型不一样呢，而且 CNN 网络在 resize 的图片比例不一样需要 padding 的话，如果模型训练时没有加入 padding 识别的话，识别率会不是很行，似乎还有如果你训练图片完全用的正拍，但是生产环境使用时有旋转或者偏移似乎也会识别率不行，要能有效识别都要加入样本才行

@yangyaofei #6 随机数定死是初始参数一致，在训练的时候修改模型是可以前后对比模型效果，不至于因为初始参数影响模型训练效果吧，训练好的模型都是定值参数，不会受影响的吧

其实既然这么纠结于 err 这个问题，以其做这种更丑陋的方案，为啥不更进一步，直接用 panic 加 recover 的逻辑做一个 try...catch 就是了啊，反正 golang 自己就能操作自己的底层内存栈堆，panic 加 recover 本来也实现好了调用栈回收的过程，汇编编写个函数，调整一下 try 位置生成的汇编代码应该是可以实现的吧，仅猜测，不知有没有大神研究过这个问题

这种东西都支付宝微信都发过无数波了吧，所以只是想在支付宝微信上干这事，你不是应该直接去找支付宝微信商务去聊么，人家应该有现成方案的吧，发放、核销、分账、风控整套的吧，没必要在这问吧

@PMR #1 金价很可能要进入下行周期了，如果这样又是很多年了，22 年看这未来行情还是保守点好

而且你们之间应该是合伙创业之类的关系，不再是雇佣关系了，风险收益自担，估计不会受劳动法限制，但是吧大家都要实实在在的生活，谁也不能靠画饼活啊，谁会愿意遥遥无期的参与限制要求颇多又没收益的事情呢，说来说去还是白搭，否则和现在开源社区不会有啥区别

说这么多，不就是期权合同么，很成熟很常用的了，期权本来就是一份法律承认的合法合同么，约定了在未来达到某些条件时你可以以怎样的条件获得某些收益，条件可以是上市或者项目达成，收益可以是股票也可以是现金或者其它的吧

赤足跑脚弓承受的冲击肯定更大，膝盖的冲击力肯定也更大了，毕竟城市里跑，用跑步机也好还是塑胶跑道，缓冲都毕竟小，而且基本完全平的冲击力太固定，这样还是很伤的，最好还是穿好一点的跑步鞋，有时间也要跑一跑凸凹不平的土路啥的，有助于保持关节受的冲击平衡

说起来今年估计完成 95%锻炼吧，不到 600 公里，基本只跑 15-20 分钟了，膝盖真承受不住，改 30-40 个俯卧撑蛙跳和 60 个左右哑铃了，其实习惯了并不累，而且不锻炼还感觉身体很重浑身不舒服，也别在逼自己吧，贵在坚持

@msg7086 #10 10 楼说的对，这种十分基本的函数会有针对不同平台、不同 cpu 版本、不同指令集的对应汇编级实现，汇编的实现函数会在上层用宏来定义，你找不到具体实现可能是 ide 不能识别汇编函数定义，而且有可能不同版本的汇编函数定义过程是不一样的，很难找的，其实这个函数语义很简单，你不用管不用怀疑具体实现怎么做的吧，真想了解似乎你直接编译后 objdump 看汇编代码更有意义吧

中小型项目这个问题真挺难解的，实际项目中，统计需求基本难有规划，基本需要啥你就给我出啥，这个主要还是一般产品似乎都搞不定这个，运营知道要啥数据但是基本也搞不定组织规划的问题，大多数公司基本又觉得专门的数据开发岗多余，确实不好解决，此外不重视自然研发这边难有统一规划，比如写个脚本不管出错重入啥的，所以啊，想要做的好，就得重视按正常产品流程来，独立的数据统计项目，不仅看眼下需求，要做良好得分层设计，完善的出错恢复监控流程

其实统计和正常产品两个逻辑是很不一样的，不应该在同一套数据表上实现两个逻辑，当然很多人觉得平时需求开发都完不成，哪有功夫仔细规划，其实如果仔细想想看的话就发现这个并不会花很多功夫，数据只要做好了数据拆分重组的逻辑，剩下基本都是数据同步的过程了，逻辑简单很多，平时多注意点，慢慢 bi 的逻辑也就建立起来了，否则就只会越来越乱

之前我们的项目也这样，简直坑死，搞到后面数据需求多了，感觉一大半时间都是在导数据，太折腾人了，但是慢慢注意了一些，其实好很多，之前做过一个项目，用 json 来定义数据同步计算过程，其本身也限制了一次只能同步一层的数据，既是限制也是规范，算是参考吧

https://github.com/snower/syncany

服务发现除了要能找到，异常、故障、宕机了也要能让使用方即使知道踢出该节点的啊，这可是双向的，不是单向的啊

gre 组网如果放在网关上是不能和两个机房在同一网段的，否则会冲突，除非你在每台机器上都配 gre 隧道，这种且不说维护难度太高，而且好好的千兆万兆内网非要搞个隧道，网络性能白白损失你这是要干啥

再说用 C 网段的话，不是每家公司只会有一两百个节点的，用 A 、B 网段可以组件更大网络，但是关播流量是不是太高了

最好 mdns 作为系统级服务，也就意味着不止你一个服务会用这东西，其可控性可预知性是不是太弱了，大型分布式系统都是要求高可用高稳定需要持续服务的，你这不是给自己埋坑么，分布式系统都搞出来了，搞个更可靠的服务发现过程又不是啥难事，为啥要用 mdns