就算用 udp 丢包重传不也照样存在？就算用 udp 不照样需要重排重组重传算法，有啥区别，或许在多个请求间增加一点点性能，但也不可能很大吧，最大省的应该是连接的三次握手吧，现在这网络速度还能有人体感知提升你幻觉了吧

python io 并不是最大限制，语言自身性能本来就比不了静态编译型的 go，这个没办法

既然函数已经繁忙于某重 cpu 事情无法返回处理其他事情，他又怎么能知道自己有没有超时呢？这本来就是互斥的，不用多线程强行 kill 没有其他方案了吧

@whwq2012 #1 现在几乎都开车，需要啥公交，这几年国家花了大力气修建农村自然村道路和水电网络，以及村小诊所，力气并没有白花

@Unclev21x #15 这个几个问题，我觉得都可以归结为一个，基本都通路，都有车，所以问题并不如想象的大，哈哈

@zjuster #31 如果是支付宝出售的话，这算违法违规了吧

@mcluyu #25 没用过丰巢寄过件，也没完成他的实名认证。。

@Yuicon #30 这个的问题是，短时间不会有啥问题，但是长时间来说，谁能保证几十年里不会有对你心怀恶意的人，就怕麻烦

@petelin #38 这不用想吧，多人协作中，至少各业务是分开的微服务组件，修改更新的至少不需要整体等着大半夜统一重启更新吧，单个项目结构更简单，新人来了熟悉难道不更快，反正你又不是大佬一来就负责所有业务
伸缩性更不用说了，那个服务性能不够了，再加几台机器就是了，多简单
业务适应性更新更不用说了，就现在这行情，上个月卖水果，这个月就可能想着做金融的，微服务化的至少你不用担心做新项目的时候还不知道哪把老项目改出 bug 来了吧，老的项目或者直接废弃或者只要不挂扔在那不管就是了，这还不比你单个复杂项目适应性更强？

微服务提高的是开发维护效率，伸缩性提高，业务快速变更适应性明显增强，运行效率必定是降低的，稳定性要求必定更复杂，这不用说啊

@dji38838c #12 我觉得以前收集的和隐私相关信息或许都不会威胁个人安全，但是个人生物信息就不一样了，那天万一泄露了，手机还可以换个新的，人脸你是要去整容么，看看现在手机号泄露满天飞的

而且感觉最近风向开始转了吧，毕竟融入生活太深了，看看谁会成这个出头鸟

@cest #6 就算以后会有大范围公用追踪系统，但也应该只有公安系统可以使用吧，普通企业并不能使用，不过这个其实也是严重不合理的，太危险了

@JCZ2MkKb5S8ZX9pq #4 这个比喻不合适吧，线下这样之所以是安全的是很多条件的，比如线下不借助现代科技手段几乎很难百分百想另外一个人完全传递我的信息，受现实限制，这个信息不会很快扩散至很大范围，在他遇到更多人或者时间变长的过程中会渐渐忘却我的信息，我觉得不安全时可以选择不在去让他忘却我或者改名、搬家等等，如果对方利用这些信息跟踪监视啥的我们是很容易发现并选择主动避开的

但是支付宝微信这样的线上大不一样吧，且不说百分百复制信息多容易，而且不管过多久这个信息任然存在，不管你到哪也任然存在，如果他有意滥用，你几乎不可能发现，这些都是很容易威胁个人安全的存在，谨慎使用时必须的吧

关于爬虫这个问题，所有爬取信息必须得到信息方许可这是强制要求啊，否则就是违法行为，这也不一样吧

我个人认为人脸数据使用应该和上传时预先告知或者和人常识使用范围一致，不得用于超出范围，使用时告知不应该被允许

@Jirajine #3 但是不管你 tos 怎么写，都不得违反当前法律法规，侵犯用户权益，否则你写的再怎么牛逼也没用啊

这样数据一致性和业务一致性都用数据库锁来保证这难道不是又是一个大坑？
如果好友申请时好友关系的一个状态，那么用数据库事务和唯一索引来保证不重复这没啥问题，但是既然你想分开好友申请和好友关系，那么这个业务一致性的要求，更应该用外部锁来保证业务流程准确是不是更好？数据库就应该简单高效准确的完成数据管理的问题，其他的都应该交给外部业务系统才是

关于用 redis 锁的问题，如果你业务量大，这不算啥吧，如果本来就没几个人用，这还想个啥子，这种同时发两个请求的极低概率问题，遇到本来就微乎其微，去他丫的了

python 协程本来就是 future 调用链，单线程又是线程安全的，想实现 go 的 channel 逻辑很简单吧
用两个变量，一个数组一个 await 等待对象，处理协程运行的时候判断下数组为空则创建一个 future 对象赋值给 await，然后等待 await 对象激活，数据协程则先往数据组中存入数据，判断下 await 对象存在且未激活就激活 await 对象，这时候处理协程就返回开始运行，取出数组数据处理就完了

贵重贵重，不重怎么能贵呢，产家如此想

@v2hh #9 平台的支出不就是用户收入么？所以应该是没有平台的表，只有用户的收支表，结余就是平台亏损或者盈利，这种情况下，余额应该是流水账加和得到的

再抽象一点来说，整个业务有一个收支总账，和平台相关还是和用户相关没有直接关系，把记录财务流水账的表和记录业务场景的订单表分开，业务流程驱动订单变更，订单完结产生财务流水，订单流程异常没有产生正常财务记账则无效，这种情况下应该走业务相关的异常订单处理来纠正，财务只应该和财务记账相关

@phantomzz #13 如果你说的是操作系统那个可重入锁的话，认真说这真是个很不严谨且偷懒的设计，web 这种场景中更不应该出现，难道你只加锁不解锁的么，需要啥重入

而且你这给出建议不考虑实际场景啊，大多数情况下，加个锁增加的 io 多还是队列异步中后台一大串 io 多，还不说维护复杂性在那呢，大多数场景下，加锁加直接该数据库库存是最容易实现最容易维护最容易稳定的方案了，能在这种情况下用满数据库 IO 的都已经是很高销售额了