这个只是你新手初期有问题，离得近即是历史原因但更重要也是为了可以单脚操作，单脚操作在熟练后完全可以基于低级神经条件反射立刻做出反应，如果离得远就要双脚分别控制，基于人左右脚不同大脑控制，那么切换的时候需要逻辑思考协调动作，紧急情况可能增加反应时间，多练习练习你就会发现紧急情况下你还没反应过来，脚已经踩死刹车了

优秀，GO 编译成 WebAssembly，但是居然不是一个 client 连接远程服务器

但是 14M 的 wasm 真是打开卡到死啊，而且为啥 wasm 要当做 css 返回！

减肥是个长期活，别这么着急，太累很容易放弃，同时也很容易反弹，一年之内减个 10-20 斤就差不多了，慢慢来也很容易养成长期习惯，比较容易保持

而且不需要强行看体重吧，男生的话体脂百分之 17 左右应该是很容易坚持的，更低感觉就需要更细致更专业饮食和锻炼了，太难

就现实情况来说，大多都会需要多帧链路层包才能发送一次请求数据，再者嘛，发送接收端无法要求或者保证中间节点都校验了，所以应用层完整性建议几乎是必须的，如果接收方不做校验那么自然无法区分正确与否，也许本来就是这样的呢

看看系统负载呗，一直用的 ac68u 刷梅林之后发现有时会出现 cpu 一直沾满的情况，估计啥地方有问题死循环了，后来就不想折腾了还是刷回官方固件，但是偶尔还是会出现挂的情况，真实坑

带 20 多台设备肯定带得动，要么看看是不是信道冲突，设备间相互干扰，不过话说现在智能设备几乎都用 2.4G ，电脑手机一般用 5G，应该是分开的啊

有了 socket 还有啥不能干的，想想看某天百度哪个产品经理脑洞大开，百度一下，来个悄悄拍的私照啊什么的直接帮你发布在微博，嗯，你就上热搜了，是不是太过刺激了一点

不是据说密码法生效后，网站泄露用户密码是违法的么
楼上说网站没有责任为用户密码加密加盐，保证明文不会泄露窃取，你们是认真的么？谁说没责任了，作死也不能这么作吧

量不多精度要求也不高的话，crontab 其实挺好用的了，每分钟查询判断下就是了
延时队列的问题是无法撤回或者修改，也不是幂等的，容错要麻烦很多

https://github.com/snower/forsun

可以看看之前做的定时调度服务，可以通过一个 key 创建一个定时任务，重复创建幂等，可以方便的撤销修改，任务保存可以使用 redis 持久化任务信息，不担心丢失，最小秒级定时任务高效，支持 http 接口和超时触发请求 http 接口

@maomaomao001 #35 但是这明显是个不合理需求，web 从设计之初想的就是无本地依赖话，大量文件的存储应该有网络来完成，本地保存大量文件本身就不符合 web 随处可用的思想，也正基于此，我们打开访问网页才很随意很方便，不用担心有任何网页会在你设备上大量保存文件，也不用担心你无意中在某个不安全设备访问网页后保留你私人数据造成不安全因素，要求使用这个管理设备依赖这是不符合 web 设计思想的，也是极其不合理的

从未来看，个人设备会变的越来越多，管理设备依赖将会变的越发困难，所以设备无关的 web 才是更好的，数据保存应该全部有网络来完成，集中管理集中授权

web 是安全与便利性妥协的完美，完全读取文件权限如果只能读写自己保存的，那么现在的 localstore、db 不好用么，如果能随意读写谁还敢随意打开你的网页，网络也是相似的，直接拥有底层网络权限，你这跨域限制还有个毛用，你想象一下你打开一下百度，就给你自动发了篇微博，图片用的还是你家里 nas 保存的私房照，这样的 web 太优秀了吧，各种硬件更不用说了吧

沙箱什么的太不认真了吧，如果拥有底层完整权限就不可能有沙箱，让用户授权确认就更扯了，且不说各种手残的，还有各种伪装欺骗点击的等等等，不要把世界想的太善良，而且不能说用户点了有损失就怪用户吧，你造了个手雷给一个普通用户弄炸了怪用户手残不适合吧

web 是一个开放式去中心话的协议，小程序则完全是由微信背书保证安全完整性的，他即从小程序生态或许巨大利益，同时也是整个生态主宰者，予取予夺，但是微信也承担了对小程序安全性的责任，出了问题微信要负责

事实上如果你周末不出门乘车，然后你会发现你还亏了，之前支付宝地铁优惠就是这样的，看起来挺便宜，仔细一算，擦了，还亏了

8 千个人授权，真个人买不起。。

@Hyseen #36 如果是第三年续费，那应该就是每年 3 折了吧，真便宜了，哈哈

不是据说 celery backbend 用 redis 支持不是特别好么，最简单就换个 backbend 呗，rabbitmq 的支持应该不错
之前用 go 实现过分布式 event，用在这个场景估计也不错

@jedihy #24 问题不是丢不丢包，是丢包多大比率的问题

@chinawrj #25 搞的换成 udp 就不需要拥塞控制是的，扯不扯

@loong0xf #18
@yyfearth #17 我想说的是任何技术方案的进步和思考都是有好处的，我钦佩他们的工作和思考，但这不是 0 或者 1 的问题，没有任何一个技术方案会成为银弹，能够在任何场景都带来良好的效果的方案是不存在的，良好技术方案是基于细致理论和工程限制选择取舍的结果

http 使用广泛不止在于浏览器端，其良好的适用性也在于其协议十分简单，这即代表这协议结构简单同时也是实现简单和协议状态管理的简单，用 udp 取代 tcp 多路复用带来了三次握手和多个请求间头部阻塞的性能提升，但是同时由应用层实现的重排重组重发 ack 算法必然增加协议实现的复杂性，有协议实现来实现的连接管理也使得 http 简单的无状态变成部分有状态化，在简单应用网络条件又日趋良好的环境下确实带来非常大收益，但在应用交互日趋复杂的趋势下，这个改进却又是明显利大于弊的，任何技术方案的思考进步都不可能是没有负面的，这再正常不过了

人云亦云，不能对技术方法实现以及现实场景做出理性细致独立思考不是一个好技术人，这也不利于自身进步，谷歌是跨国公司巨大的浏览器占有量和 web 跨国访问量，udp 取代 tcp 以及应用层实现的所带来的性能提升和价值收益是显而易见的，其所做工作和尝试并不能被否认，但是其是否具备广泛适用性和把 http 协议变成一个更复杂协议是否适合确实值得思考

@yyfearth #17 关于丢包这个问题我觉得你可以多去看看底层 ip tcp 再下结论，tcp 存在丢包重传，udp 仍然存在，基于现实甚至可能更为严重，这个是任何协议都无法规避的问题