技术人说话多数都比较直, 一不小心就闹矛盾了

@kenvix
如果写到多个文件, 每个文件可以自带上一个元信息, 即使任务中途失败导致下载器退出之类的, 以后还可以从上次下载的地方继续. 直接写入到目标文件, 没有这个元信息, 如果中途失败退出了, 下次只能从头来.
对于大文件低带宽不稳定, 不能确保单次操作下载完的情况下, 直接写目标文件不划算;
而即使是 10G 这种大文件, 本地多个分段文件做一次合并的开销和耗时也几乎可以忽略不计.

另外, 分段下载如果对方响应的数据不是 trunked, 而是 content-length, 不同平台或许还可以利用 zero copy 优化避免先读取到内存再写入文件, 既减少应用层内存开销也提高速度, 多线程直接写入 queue 再写入目标文件的方式不好做这些. 不过这些本地 io 和只是读写 buffer 的内存开销本来也不大, 即使能做提升也不会太大.

@ipwx #4 太贴切了

@gtese 我那么说是因为我这也是亲身体验, 看一圈医生, 老中医正骨推拿, 膏药外用, 中西药内服, 都试过, 所谓的缓解一点其实只是相当于手法治疗时候休息了下感觉舒服, 停止治疗就不行了. 正骨主要是你骨头发生位置偏差时候强力矫正回来的瞬时效果, 真正巩固需要自己加强锻炼, 不锻炼则肌肉群无力, 骨头照样继续偏移回去病态, 推拿则是放松肌肉促进血液循环, 同样道理, 自己不锻炼, 手法给你缓解下, 依旧错误的生活工作习惯, 肌肉群照样无力僵硬和病态. 至于用药, 也是同样的道理, 外力适合急症和辅助, 只要自己肌肉不够强, 长期错误姿势都会让病继续, 而且外用药伤皮肤, 内用药那也是是药三分毒额外要伤五脏六腑加重负担. 颈椎分几个阶段, 你这还没到最后的那个什么锥节都连一块的状态, 锻炼是最好的治疗方案. 打太极, 适度和适合的健身方法之类的, 都可以, 我也在锻炼身体, 对比下来的感觉就是, 吃药正骨推拿既浪费钱又收效甚微停了就加重, 锻炼比它效果好多了.

别被定义懵逼了, 别以为锻炼就只是锻炼, 其实锻炼是最好的治疗. 即使看医生, 靠谱的医生不只是给你正骨推拿开药, 还要教你一些锻炼的方法并且让你保持锻炼, 整个治疗方案里, 除了急症用手法和药物缓解, 平稳康复期里, 锻炼和保持是最重要的环节, 否则正骨推拿吃药花多少钱都是白白浪费钱和时间

别在这浪费时间了, 求医救不了这些职业慢性病

你细想想, 正常健康人都能生病, 你吃药看医生也只是辅助恢复, 即使好转一点, 现在的生活工作习惯仍然会复发, 所以没办法的, 根本问题在于改变生活工作里的对身体不利的坏习惯, 加强锻炼

要么改变和锻炼, 要么就慢慢被折磨到死吧

OP 是法国人?

没有人能在法国投降之前占领巴黎
没有人能在 OP 认错之前批评 OP

@liaojl #1

上班如上坟, 烧纸供法人

充电限制下到 85%以内，其他的，如果是作为工具提高自己能力，那就可劲造、不要太爱惜它

这么多年下来我是总结明白了，工具的东西跟妹子是一个道理，过度爱惜呵护、相敬如宾那不是爱情，咣咣猛干的才是。

所以，除非你是作为娱乐想省钱，除非是图书馆借来的书要讲义务和道德，否则，蹂躏吧，把这些用来提高自己的东西蹂躏得越狠，自己提高得越多、收益更大

@iseki 我专业摸鱼十多年，幸好公司没跟我搞事情，否则。。。他们也不知道我这个号是我。。。

> 综上，对于智力产出者而言，最好不要写代码，可以考虑像刘慈欣一样写小说：

@charlie21 可惜了，CURD 易，搞创作难

@jhdxr
你可能没拎清楚，从法律角度讲确实是 CEO 说的没问题。但很多人反驳那个 CEO 考虑的根本不是法律范畴问题，就像 Nginx 之父被捕，几乎都是声援 Nginx 之父而不是支持他公司这样用法律大棒搞开发者。国内之前的案例也是有一些、都支持了公司维权。但正是这些靠法律维权开源贡献者（这里尤其是指那些为爱发电没有用来牟利的）的行为越加让广大开发者群体觉得反感。
别人提出这个观点也主要是为了声援站队贡献者、本质上是站队开源精神，只是为了从道德逻辑上反驳 CEO 罢了，你要是较真这其中的逻辑就没意思了，涉及到精神层面的很多事件都不是真讲逻辑道理的，否则这世界还哪来那么多宗教

而且现实世界不就是这样嘛，法律是维护社会整体稳定的工具，任何现行的法律条款都不能完美协调所有场景所有人的满意度。

所以我觉得这玩意咱就分开说比较好：
1. 法律上，CEO 是懂法的
2. 道德/开源精神上，CEO 是个什么玩意

但不管从哪个方面讲，只要你让我站队，我铁定站贡献者，我相信大多数人也是站这边

@mbeoliero123 #1 估计 OP 不是高技术的、以为 `django` 这个词里的 `go` 就是跟 golang 有关吧

为了帮助程序员群体, 希望 OP 招 3(个)募 4(个), 希望 OP 朝 3(楼)暮四(楼)

被小米几轮营销洗脑之后, 我终于决定下个车换保时捷了

@momobear 代沟了, "红温" "下头" 这俩词我都不懂是啥意思...

> 这代年轻人会因为不好的感受下头不是一个很正常的事

如你所说, 这代年轻人容易"下头". 既然这么容易下头, 那我觉得脆皮也是我的正常感受啊, 所以我对你"对我的思考角度感到难以理解" 也感到难以理解...

@momo24672 期待各位反对 POST 一把梭的早日加入 POST 一把梭大家庭!

@momo24672 #117
正如我前面讲的, HTTP 本身的设计侵入了用户自己的应用层协议, 它既负责数据传输, 又自定义了太多应用层相关的协议, 如果只做静态资源文件服务之类的特定简单可控的场景, 那么它自己相当于是应用协议, 这样设计或者这样使用倒也凑合, 无可厚非.
单就 HTTP 还有一些其他的我在其他帖子里有聊过, 比如 HTTP 自己既有 Method, 又有 Router, 然而一个协议交互主要就是表明亮点: 要干什么, 干这个需要什么. 这两点, 主要体现在协议头和包体. 这世界上可不只是有 web http 的开发需求, 其他领域自定义的协议通常都是比这简化的, 主要满足这两点——协议头和包体, 比如 RPC. 除了 HTTP, 我在其他领域比如 IM, 游戏, 音视频, 各种领域的协议, 我几乎没见到过协议头自己也分两层的: 一层 Method 另一层 route. 而且你认真地想一想, Method 分这么多真的有必要吗?没有它就解决不了现实问题了吗?显然不是!

复杂的现代业务需求, 应用层自己要做很多业务分支状态码, 如果同时要兼顾 HTTP 自己的, 要多思考一层, 比如这里争论的到底是用 GET 还是 POST PUT DELETE, 有的团队有的开发者还要琢磨到底是直接按 HTTP 的状态码比如 403 还是统一用 HTTP 200+自己应用层的错误码. POST 一把梭的方案, 主要就是屏蔽了这些 HTTP 自己的东西, 业务集中考虑自己业务层的协议设计, 这既符合分层原则, 也减少了兼顾两个协议层次的设计的耦合, 所以这是简化复杂度.


具体的可能需要你实际体验一段时间以及深入思考下才能体会到.
如果还是无法理解, 那建议也不要随便下结论去武断地认为是别人 sb, 也需要反思下是不是自己当下见过的世界是不是有点窄到只了自己暂时狭隘了...