@ipwx 不熟悉设计模式，请教我如何写比较符合模式，谢谢。

@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 当然是能够解决，我只是综合考量失效后成本和备份成本，感觉这样对抗电子衰变已经可以接受了。