@Mohanson 我觉得不要乱科普，弱检查跟弱类型是两个概念。char 能和 int 相加有轻易明确的底层逻辑，与 js 的 1+'1'不是一个概念

@misaka19000 题外话，我觉得喜欢动态类型的人不少，但应该不会有人喜欢弱类型

@addidd 感谢，已解决。百度半天找不到关键字

不同服务商走不同网络线路，很正常。比如 http://ping.pe/当中做测试的时候你经常可以遇到某些线路连接海外服务器不丢包，另一些丢包严重的情况，感觉大概率这个问题不是 lz 能管得了的

@msg7086 比较震惊，有种这么多年 C 语言学的都是错的感觉。C 是少数专门啃过语法书的语言，但是这么多年其实没怎么写过。所以意思是主流语言的设计，GNU 的 C，java，js，都是可以实现能访问即能修改的，py 属于异类？那么禁止修改这是一种错误的设计么

@msg7086 我是手机发帖没法直接测试，我上文的代码里 gcc 中 func 可以直接修改 data ？这么魔幻

@Mithril 感谢回复，但我觉得这个不算做问题的解答，因为单纯讨论特性的话大部分语言往往兼具两种，即他可以面向对象，同时也可以使用闭包保存状态，但是这不影响不同语言对命名空间的处理

@seki 这里只是举例，不讨论实现本身，用 var 和 let 不影响代码行为，我觉得用 var 更能体现一些特点所以用了 var

@wzb0909 谢谢，block 了

@todd7zhang 我其实不是很理解 tcp 的有序性，因为之前朦胧印象中实验结果与理论上不符，不过因为是很久远以前的事了也不是记得很清楚。

所以理论上如果仍然发出上述两个长请求，如果请求 1 中的某一个封包因为网络波动丢掉了，TCP 是会自动重传，再补传的封包收到前，无论 server 读取多少次，都不能从 recv 读取任何东西是吗（即使网卡已经收到了后续的封包）。

我印象中我以前的实验是 recv 始终能读出东西，丢掉的封包会被跳过，很神秘

@liprais 我个人使用过程中两种模式都没给我带来过任何不爽。但我其实很想知道如果以后还要设计更新的语言，那种模式是更合理的

@todd7zhang 感谢回复，我看了一下你的代码，感觉跟我说的不太一样，可能我没有描述清楚。我预想中的情况是，即使使用 header 标明长度，假设 client 在同一个连接中发出两次请求，分别为 herder = 102400 & 102400*'i'，即长度为 102400 的 i 字符，且带了一个描述长度的标头。之后又发送了一个 herder = 102400 & 102400*'j'的请求，即将上个请求中所有的 i 转换成 j，由于这两个请求都较长，会被拆成多次发送。

那么服务端第一次接收到 102400header 后，会读取接下来 102400 个字节作为一个请求。但接下来 102400 中未必是连续的请求 1，可能掺杂入请求 2 的内容，这种错误可能由网络波动导致，我不知道如何在本地模拟，本地由于没有网络延迟，一般 clinet 连续发出两个请求，server 也就连续收到两个请求，不太容易产生错位的情况

另外 lz 测试过基于 http 相对 tcp 构建的效率吗。我之前测试本地回环，进程间 socket 通信一个来回大概在 100 微秒这个数量级，http2 之类的协议是不是能达到类似效果？

想请问一下 lz，以前想用 socket 实现一个简单的 rpc，但是遇到问题。从效率角度讲，最好两者之间建立一次连接后可以一直使用，不需要重连。那么假设客户端向服务端发出两次请求，内容都比较长，需要拆分成多个封包发送，如果因为网络延迟，可能导致服务端收到的两个请求的封包的内容掺杂起来，这种情况应该如何解决呢

说个题外话，lz 考虑过压缩 io 流吗，最近发现压缩可以有效缩减传输量

@ivyliner 抱歉，我不用任何苹果生态产品，所以我没有 ios 或 macos

@Bijiabo 大概五年前开始就各种听说阿里云负面新闻了，最大的一次是 csdn 转出事件。我司所有服务现在也慢慢转出阿里云了，稳定没看见，价格贵倒是立竿见影

@xiangyuecn 因为实际业务场景不可能那么单纯，popen 一次就完事。实际处理中你可能需要修改已有文件，这样的话先命令行解码，再编辑，再命令行编码，可靠性和维护难度显然远低于程序内部 IOstream 一把梭，所以我称之为不能可编程化。楼上提供了一个第三方冗余，因为不影响整个操作流程，只是在结尾通过命令行调用一个附加品，所以我说这个可以。显然区别很明显。

我原贴当中就说了两种方案，用户级的备份逻辑显然是后一种选择，先问冗余肯定是因为要平衡效率和成本。比如你有 100T 的文件要备份，另外搞一些硬盘，将数据变成 200T 当然是能够解决，我只是综合考量失效后成本和备份成本，感觉这样对抗电子衰变已经可以接受了。

我很好奇这种级别的失效阿里云要负多少法律责任。感觉 ECS 失效是跟支付宝失效一个级别的大事故，如果我公司在上面运行了一些核心服务，造成的财产损失谁来负责。我很不希望听到类似于阿里云在用户协议中写明了这种情况用户自负，所以他不用负任何责任之类的故事