@2i2Re2PLMaDnghL 视为单个空格和处理内容为单个空格不是一个概念，两种处理方法都是合理的，本质上是这个问题没有良好的定义

十年前走进商店买数据线：Micro-USB ，Mini-USB ，USB-A ，USB-C......这都什么玩意

USB-IF：我们要整一个统一的接口，以后很多设备都是这个口

我：好耶

手机厂商：hAo yE ！

买数据线的我：
USB-C （ USB2.0 ），USB-C （ USB3.0 ），USB-C （ USB3.0 E-Marker ），USB-C （ USB3.1 Gen1 E-Marker ），USB-C （ USB3.1 Gen2 E-Marker ），USB-C （ USB3.2 Gen1 E-Marker ），USB-C （ USB3.2 Gen2 E-Marker ），USB-C （ USB3.2 Gen2×2 E-Marker ），USB-C （雷电 3 E-Marker ）

USB-C （ USB2.0 PD2.0 ），USB-C （ USB3.0 PD2.0 ），USB-C （ USB3.0 E-Marker PD2.0 ），USB-C （ USB3.1 Gen1 E-Marker PD2.0 ），USB-C （ USB3.1 Gen2 E-Marker P2.0 ），USB-C （ USB3.2 Gen1 E-Marker PD2.0 ），USB-C （ USB3.2 Gen2 E-Marker PD2.0 ），USB-C （ USB3.2 Gen2×2 E-Marker PD2.0 ），USB-C （雷电 3 E-Marker PD2.0 ）

USB-C （ USB3.0 E-Marker PD3.0 3A ），USB-C （ USB3.1 Gen1 E-Marker PD3.0 3A ），USB-C （ USB3.1 Gen2 E-Marker P3.0 3A ），USB-C （ USB3.2 Gen1 E-Marker PD3.0 3A ），USB-C （ USB3.2 Gen2 E-Marker PD3.0 3A ），USB-C （ USB3.2 Gen2×2 E-Marker PD3.0 3A ），USB-C （雷电 3 E-Marker PD3.0 3A ）

USB-C （ USB3.0 E-Marker PD3.0 PPS 3A ），USB-C （ USB3.1 Gen1 E-Marker PD3.0 PPS 3A ），USB-C （ USB3.1 Gen2 E-Marker P3.0 PPS 3A ），USB-C （ USB3.2 Gen1 E-Marker PD3.0 PPS 3A ），USB-C （ USB3.2 Gen2 E-Marker PD3.0 PPS 3A ），USB-C （ USB3.2 Gen2×2 E-Marker PD3.0 PPS 3A ），USB-C （雷电 3 E-Marker PD3.0 PPS 3A ）

USB-C （ USB3.0 E-Marker PD3.0 5A ），USB-C （ USB3.1 Gen1 E-Marker PD3.0 5A ），USB-C （ USB3.1 Gen2 E-Marker P3.0 5A ），USB-C （ USB3.2 Gen1 E-Marker PD3.0 5A ），USB-C （ USB3.2 Gen2 E-Marker PD3.0 5A ），USB-C （ USB3.2 Gen2×2 E-Marker PD3.0 5A ），USB-C （雷电 3 E-Marker PD3.0 5A ）

USB-C （ USB3.0 E-Marker PD3.0 PPS 5A ），USB-C （ USB3.1 Gen1 E-Marker PD3.0 PPS 5A ），USB-C （ USB3.1 Gen2 E-Marker P3.0 PPS 5A ），USB-C （ USB3.2 Gen1 E-Marker PD3.0 PPS 5A ），USB-C （ USB3.2 Gen2 E-Marker PD3.0 PPS 5A ），USB-C （ USB3.2 Gen2×2 E-Marker PD3.0 PPS 5A ），USB-C （雷电 3 E-Marker PD3.0 PPS 5A ）

USB-C （ USB2.0 SuperVOOC ），USB-C （ USB3.0 SuperVOOC ），USB-C （ USB3.1 Gen1 SuperVOOC ），USB-C （ USB3.1 Gen2 SuperVOOC ），USB-C （ USB3.2 Gen1 SuperVOOC ），USB-C （ USB3.2 Gen2 SuperVOOC ）

USB-C （ USB2.0 小米快充）

USB-C （ USB2.0 vivo22.5W 快充），USB-C （ USB2.0 vivo44W 快充），USB-C （ USB2.0 vivo120W 快充）

USB-C （ USB2.0 SCP ），USB-C （ USB3.0 SCP ），USB-C （ USB3.1 SCP ），USB-C （ USB3.2 Gen1 SCP ），USB-C （ USB3.2 Gen2 SCP ）

@amiwrong123 注意括号 然后假设每次都一致，这是前提条件。。。
来看标准吧，c++20 标准 6.3 节 13 小节
There can be more than one definition of a
... -inline function or variable ([dcl.inline]), ...
这是允许 inline 函数或变量有多个定义（即使同一个 TU ）再看需要满足的要求
(13.8)
Each such definition shall consist of the same sequence of tokens, where the definition of a closure type is considered to consist of the sequence of tokens of the corresponding lambda-expression.
每个定义都需要有相同的 token 序列
(13.9)
In each such definition, corresponding names, looked up according to [basic.lookup], shall refer to the same entity, after overload resolution ([over.match]) and after matching of partial template specialization ([temp.over]), except that a name can refer to ...... same entity in all definitions of D.
每个定义所引用的符号在重载解析，模板偏特化之后除了某些特殊情况外都必须解析到相同的实体上
最后
If these definitions do not satisfy these requirements, then the program is ill-formed; a diagnostic is required only if the entity is attached to a named module and a prior definition is reachable at the point where a later definition occurs
如果这些条件没有满足要求，那么程序是不合法的，而也只有特殊情况（同一个模块且在不一致定义要在同一个单元）才要求编译器给出诊断（报告错误）
所以一个不要求诊断的错误的代码（甚至不属于 UB ）给出任何行为都是符合预期的（链接期随意选择是结果的一部分而不是原因，写程序不是自然科学，不要用实验来推测原因）

C++的 inline 语义并不是内联函数（内联是副作用）
主要作用是允许同符号在多个翻译单元中多次出现（然后假设每次都一致），同时 inline 也要求必须在同翻译单元找到定义（除非没用到）
extern inline 实际上按标准只能做同一个翻译单元里的前向声明。
而在不同翻译单元混用 extern （无 inline ）和 inline 实际上属于未定义行为，因为不符合前面所说的定义一致原则

1G 的话实际也推不上去（得用 LFS （然后问题就很复杂了））
不考虑这个问题的话，其他人可以通过记录第一次推送时的 commit hash 来强行获取旧的文件（在 github gc 之前都能存在）

@asanelder 打包之后被压缩了啊，然后就需要边解压边读取，zip 压缩也不是固定输出大小的压缩，解压的时候也很难预测要读多少内容才能得到 1024 ，通常的思路就是读固定大小，然后解出多少就提供多少（

你把 framework 从设备里提取出来反编译一下试试？

类似的问题多了去了
https://github.com/cblp/yaml-sucks

(这一系列函数中，只有 memmove 是保证重叠的时候正确的）

什么时候改文件内容会修改文件夹修改时间了？？
Linux 下能更新怕不是因为包管理器更新时先 unlink 了原文件再创建回去造成的。。

不如一步到位直接起个数据库（划掉）
如果可以序列化成数据库的话，同一台机器上可以使用 SQLite3 ，启用 WAL 模式后读写互不干扰，可以同时进行，性能大概比每次序列化强，但是单独访问的话就不一定比 OrderedDict 快（
但是最主要的是不用自己解决复杂的线程同步问题了，而这个可是经常处理出错误的（

@1sm23 也不是不可以在安卓子系统上弄）
我记得是全局生效的

协程就是一种代码的组织结构，你当然可以全部使用手写状态机来做，事实上早期开发大部分都是这个模型。。。
作为一种结构，它可以大幅度简化某些场景的代码复杂度，这就是它最初的意义。
即使传统磁盘 IO 没办法使用 poll 的模型（因为总是 ready ），为了代码上的统一，做成线程池支撑，上层逻辑用协程描述也无可厚非（虽然现在新的 io 模型已经支持提交大量磁盘请求然后等一起完成了）
至于性能方面的提升，那有也只是副作用，即降低了编码复杂度导致可以从更高抽象角度优化业务逻辑，而不是拘泥于底层状态机的实现细节。
这里和同步 /异步，阻塞 /非阻塞其实关系不大，即使是一个纯算法，也可以使用协程来描述，generator 的模式和协程其实就差不多同构（可以互相转换），与其在需要数据时耦合上获取数据的代码，不如做一个 generator 将数据获取的过程抽象出来，generator 可以让你使用传统控制流结构来描述逻辑，同时内部状态就直接用 generator 中的局部变量表示。

Swift: ?

(先看看是不是真的要特权才能跑。。。
执行前设置一个 __COMPAT_LAYER=RunAsInvoker 环境变量试试功能会不会异常

@yangyaofei 考虑下内网有没有别的服务（
比如数据库

还有就是即使啥权限没有，也能挖矿

@feather12315 win 阵营也抄了个 Io Rings （
https://docs.microsoft.com/en-us/windows/win32/api/ioringapi/

考虑到还有原生对象，精确的复制大概是不现实的（
加上还可以 proxy