• 本文反对的不是生电、自动化或技术玩家，而是用 “原版能做”“没开作弊”“官方没修” 等单一理由，终止对玩法边界和成果可比性的讨论。文中论证来自一组不公开的具体讨论；除少量可确认的措辞外，其余是摘要、重建与为分析而提出的 “强版命题”，不代表整个技术社区。
• “生存模式” 是游戏内的技术状态，“技术生存” 是可以按社区规则纳入争议机制的玩法类别，“纯生存” 则是含义并不完全统一的公共标签。本文所说的 “严格无复制生存”，只是一套明示的可选规则，不是 Mojang 的官方定义。
• 生电不是一个足够精确的机制清单。红石运输、农场、刷怪塔、村民交易、更新抑制、TNT 复制、沙子复制和任意物品复制都可能出现在技术生存讨论中，但它们对资源、持续成本、性能和服务器经济的影响不同，不能捆在一起评价。
• “允许作弊” 是控制指令权限的技术开关；日常语言中的作弊则是相对于某套共同规则而言。私人存档的玩家无需向陌生人证明自己的玩法；但在多人协作、服务器经济、成果评比或以 “纯生存” 为卖点时，对关键规则的说明会影响知情参与和成果可比性。
• 沙盒自由保证玩家可以选择规则，却不保证不同规则下的成果无需说明就彼此等价。允许复制的技术工程与严格无复制工程可以同样精彩，但经历了不同的资源约束；坦率披露可以消除隐瞒问题，不会让所有成果自动变得可直接比较。
• Mojang 长期未修、Won't Fix、Works As Intended、开发者发言和社区概括是不同层级的证据。官方明知并保留一项机制，会显著增强玩家使用它的实践正当性；但维护容忍、设计意图、服务器允许和 “纯生存” 分类仍是可以分别回答的问题。
• 生电工程往往需要大量知识、收集、建设、调试、协作和维护，因此 “生电就是不劳而获” 并不成立。但 “整个项目很艰难” 不等于 “其中每一种手段都没有改变资源关系”；建设成本、运行成本和被取消的持续消耗应当分开讨论。
• 刷怪塔是把生成条件、建设和运行时间转化为产出；TNT 复制则让爆破持续发生而不再为每次爆破消耗新的 TNT。两者都可以有技术含量，却不因此对资源关系产生同样的影响。严格无复制生存将配方、采集来源和一次性消耗视为跨社区理解的默认起点，但不据此宣称自己在道德上更高。
• TNT 复制与世界吞噬者的流行，可以说明 Minecraft 后期存在批量爆破和采掘工具缺口，也能支持官方在没有替代方案时谨慎修复。但 “某项宏大工程只有依赖该机制才现实”，不能自动推出 “所有生存标准都必须接受它”。技术生存可以让限制迁就工程目标，严格无复制生存也可以让工程规模服从资源边界。
• 不同漏洞的复制对象、成本变化、性能影响和官方态度可以不同，因此区别对待本身不是双重标准。真正的问题是明示理由与实际标准不一致，甚至标准随利益变化。服务器规则应尽量说明限制的是复制、产量、实体数量、区块加载还是实际负载，并注明 Java 版、基岩版、具体版本和服务端环境。
• 结论不是为玩法排列高低，而是把评价落到具体机制、具体环境和具体承诺上。“原版技术生存，允许 TNT 复制”“允许世吞与更新抑制，禁止任意物品复制”“严格无复制生存” 都比单独使用 “纯生存” 提供更多信息。

问题不在于你怎么玩，而在于你如何命名

生电是 Minecraft 社区中极具代表性的一种玩法。它把红石、刷怪机制、村民交易、区块加载、方块更新和资源生产组织成一套复杂的工程体系，也让许多在普通生存里近乎不可想象的大型项目成为可能。一个成熟的技术存档，往往凝结了玩家对游戏机制的长期研究，也包含大量设计、试错、协作和实际建设。否认这些知识与劳动，不仅有失公允，也无法解释生电玩法为什么能够发展出稳定的社区、术语与技术传统。

因此，本文反对的不是生电玩家，也不是自动化本身。玩家当然可以在单机世界中制定自己的规则，服务器也当然可以允许 TNT 复制、更新抑制、世吞或其他争议机制。沙盒游戏的魅力，本来就包括创造目标和重写玩法边界的自由。

本文的出发点是一组具体讨论中出现过的论证，而不是一个想象出来的群体。出于隐私考虑，本文不公开发言者的姓名、时间和账号信息，也不把个人发言当成整个技术社区的统一立场。由于原讨论不随本文公开，且其中的官方链接现已遗失，下文只把能够确认的简短措辞作为原话，其余均是对当时论证的摘要与重建，不用来证明这些观点在社区中有多普遍。在这组讨论中，一位技术玩家先后提出：“因为 Mojang 没修”，长期未修或标记为 Won't Fix 的 bug 便成了特性；开发者允许玩家利用这些机制，因此使用它们 “没问题”；TNT 复制填补了大规模破坏方块的工具缺口，保留它是出于游戏平衡；生电前期并不轻松，所以后期的高效产出是长期劳动和技术投入应得的回报。同一讨论中还出现了高铁与骑马、无线通信与写信的类比，以及把刷怪塔拆解为 “造房、不插火把、修上下通道” 等普通操作的辩护。

这些论证都有可讨论的部分，也比 “生电就是不劳而获” 更有力。本文真正想检验的，是将这些理由推到最强时所得的主张：只要某件事能在原版客户端中完成，它就当然属于任何人理解的 “纯生存”；只要没有打开设置中的作弊开关，就可以终止一切关于玩法边界的讨论；只要 Mojang 长期没有修复某项机制，维护决策就自动等于对所有社区分类的最终裁决。这是本文为了分析而明示写出的 “强版命题”，不冒充任何发言者的逐字原话。当 “技术”“原版机制”“作弊” 和 “bug” 只随着立场变化，却不说明判断标准时，这些词就不再只是描述机制，而是在争夺谁有权定义 “正确玩法”。

我的立场其实很有限：生电当然可以存在，也完全可以成为一种有技术含量的生存玩法；但其中一切手段不会仅因 “原版可执行”，就自动符合所有共同体对 “纯生存” 的理解。尤其在多人协作、服务器管理、成果比较和玩法分类中，玩家采用了什么规则，应当比是否按下某个开关说得更清楚。

“生电” 不是一个足够精确的判断

讨论生电时，一个常见错误是把性质不同的行为捆在一起评价。红石运输、作物农场、物品分类、刷怪塔、村民交易体系、更新抑制、方块状态操纵、TNT 复制、沙子复制和任意物品复制，都会出现在与技术生存相关的讨论里，但这不意味着技术社区普遍接受它们，更不意味着它们都是 “生电” 的必要组成。它们可能都需要游戏知识，却不因此对生存约束产生相同影响。

通过漏斗和红石实现自动运输，与直接复制本应消耗的物品，并不是同一种效率提升。刷怪塔利用游戏的生成条件，把选址、结构和挂机时间转化为产出；常见的 TNT 复制装置则能反复产生用于爆破的点燃 TNT，而不要求每次爆破都重新消耗一块由玩家制造的 TNT。两者都可能需要建设和调试，也都可以用于宏大工程，但 “都有技术含量” 不能抹去它们在资源关系上的差异。

这一区分也意味着，批评某些复制机制不能直接扩大成对一切自动化的批评。村民交易、刷怪塔或红石农场不能仅仅因为效率高，就被轻率地称为作弊。一个玩家把正常生成机制组织成高效生产系统，恰恰可能是在游戏规则内用建设投入换取长期收益。反过来，生电玩家也不能因为正常自动化显然合理，就把这种合理性自动转移给所有争议机制。证明刷怪塔不是作弊，并没有同时证明 TNT 复制不是漏洞；证明一台世吞非常难造，也没有回答它所依赖的每一项机制是否符合某种严格无复制生存标准。

这里还需要澄清 “作弊” 一词。在 Minecraft 的界面中，“允许作弊” 是一个技术开关，它主要控制指令等功能是否可用。但在日常语言里，作弊通常是一个相对于规则的概念：只有先存在一套已经声明或可以合理预期的共同规则，才能判断某个行为是否违反了它。因此，没有开启作弊开关，确实能证明没有通过该开关取得权限，却不能单独决定所有机制利用都应如何分类。另一方面，在没有比赛、服务器规则或共同承诺的私人世界里，玩家并不欠别人一套玩法证明；此时是否使用 “作弊” 一词，更多是个人分类，而不应变成对他人的人格判断。

为避免这些词相互替代，本文先区分三个层次：“生存模式” 是游戏内的技术状态；“技术生存” 是可以按共同体规则纳入争议机制的玩法类别；“纯生存” 是跨社区使用、含义并不完全统一的公共标签。本文另用 “严格无复制生存” 指一种明示的可选规则集：尽量保留资源获取、风险承担和时间投入，不使用会直接复制资源或持续保留本应消耗对象的重大机制。这不是 Mojang 规定的官方定义，也不是一条仅凭直觉就能裁决所有边界案例的原则。普通农场、刷怪塔和村民交易同样会大幅降低边际资源成本，因此 “后期成本很低” 不能单独成为排除某项机制的理由。真正需要说明的，是这套规则特别保留哪些成本，为什么保留，以及边界案例由谁根据什么标准判定。提出这一区分的目的，不是宣布一种标准统治所有世界，而是拒绝把不同标准压缩成同一个模糊标签。

评价具体机制时，不能只问它是不是 “原版”。还需要问：它是否直接复制或保留本应消耗的对象，取消的是一次性的建设成本还是持续性的资源成本，官方是否明确说明过设计意图，共同体是否事先允许并向所有参与者开放，以及它会怎样影响服务器性能、经济系统与成果可比性。“它是不是程序漏洞”“官方是否容许它继续存在”“某个服务器是否允许使用”“它是否符合本文所说的严格无复制生存”，是四个可以分别回答的问题，不能相互代替。

严格无复制生存对 TNT 复制的拒绝，其实有一个很朴素的理由：TNT 本来就是会消耗的。沙子要挖，火药要获取，TNT 要合成，点燃以后它就没了。复制机最根本的作用，就是让爆破继续发生，却不再为每次爆破付出这份成本。装置再复杂，世吞再难造，也不会改变这个事实。拒绝它不是嫌产量太高，而是不愿意把 “本应消耗的东西不再消耗” 算作普通自动化。这条线未必能解决每个边界问题，但它绝不是没有内容的固执。

这条线的根据也不只是把结论写进定义。配方、采集来源和一次性消耗，是游戏持续向普通玩家展示的资源关系；玩家无需先研究隐藏机制，就能据此形成 “一次爆破通常对应一次消耗” 的稳定预期。因而，当 “纯生存” 被用于跨社区展示或比较时，这种可见的资源关系可以成为一种默认但可被明示规则修改的理解起点。这不证明它在道德上高于社区惯例，却说明了为什么在比较成果时，直接取消这种消耗关系值得被单独说明。

偶然撞上一次 bug，和照着教程为它造机器，也不是一回事。前者可能连玩家自己都没意识到，后者的目的就是稳定、反复地利用它。因此，“我的存档没有利用已知复制漏洞” 是可以实际遵守的承诺，不需要等 Mojang 替玩家列出一张穷尽所有 bug 的官方清单才能成立。

从这一角度看，“原版可执行” 只是最低限度的技术条件，而不是对取得过程的完整描述。一个存档可以始终处于生存模式，其中的资源却可能分别来自常规采集、自动农场、复制机制，乃至管理员回档。把它们都概括为 “原版生存中能出现”，会丢掉正在被比较的信息。严格无复制生存将一部分机制排除在外，目的并不是证明自己更能吃苦，而是让 “这些资源如何来” 仍然能从标签中获得大致回答。

这也涉及一个举证方向的问题。当某项技术的运作结果明显违背配方和消耗关系时，不使用它的玩家不必先证明该机制 “道德上错误”，才能把它排除出自己的严格无复制生存标准。相反，如果有人要求 “纯生存” 必须包含这项机制，就需要说明为什么 “原版能做” 足以压过资源消耗关系所形成的直观预期。这不是把一种私人规则宣布为官方定义，而是拒绝让 “程序没有阻止” 成为不需要继续说明的默认答案。

沙盒自由允许选择，不保证所有选择等价

另一种常见回答是：“Minecraft 是沙盒游戏，想怎么玩都行。” 这句话本身没有错。有人喜欢徒步探索，有人建设交通网络；有人手动砍树，有人制造树场；有人严格排除复制机制，有人把研究更新顺序和方块状态当作主要乐趣。只要不破坏他人的世界，不违反共同规则，这些选择都不需要得到陌生人的许可。

但沙盒自由只能推出 “玩家可以制定规则”，不能推出 “所有规则下的成果无需说明就彼此等价”。一个创造模式建筑、一个允许复制机制的技术生存工程和一个严格无复制存档，可以同样精彩，却显然经历了不同的资源约束。指出这种差别，不等于贬低其中任何一方。真正不尊重沙盒自由的，反而是要求所有人使用同一个标准：无论是技术玩家要求别人承认一切原版可执行行为都属于纯生存，还是严格无复制生存玩家跑进规则公开的技术服指责其中所有人作弊，都把自己的玩法边界强加给了别人。

在私人世界里，“你不用就行了” 通常是一个足够好的回答。但当玩家主动参加成果评比、共同建设、服务器经济活动，或者以 “纯生存” 作为作品卖点时，规则便不再只是一项私人偏好。此时说明是否使用 TNT 复制、物品复制、更新抑制或其他会显著影响过程的机制，是为了让参与者理解成果是在怎样的条件下取得，而不是要求作者为自己的游戏方式道歉。

沙盒提供选择权；进入共同活动，则伴随着说明规则和接受评价的需要。这两件事并不矛盾。

这种说明义务也不应无限扩张。普通作品展示并不需要附上一份机械百科，只有当某项机制会实质影响比较维度，或者观众有理由根据 “纯生存”“无复制”“原版” 等标签形成特定预期时，补充说明才尤其必要。披露的目的应是避免误解，而不是制造一套繁琐的资格审查。

沙盒的自由也不只体现在扩张可用手段上。主动保留稀缺性，接受某些工程在当前工具下过于昂贵，或因为不愿利用非预期行为而缩小工程，同样是在利用沙盒提供的选择权。对这类玩家来说，限制不是急待克服的障碍，而是让采集、规划和取舍保持意义的条件。把这种选择说成 “不懂自动化” 或 “只会坐牢”，同样是在把一种玩法标准强加给别人。

“纯生存” 也不能被完全化约成圈子内部的任意定义。一个标签之所以能用来展示和比较，正是因为它让不熟悉某个特定社区的人也能形成大致预期。技术社区可以在内部稳定地把 TNT 复制纳入技术生存，但当作品只使用 “纯生存” 面向更广泛的观众时，不能当然假定所有人都熟悉这套内部惯例。在这种场合补充 “允许 TNT 复制”，不是向外部偏见低头，而是承认标签需要跨语境传递信息。

说明规则能够消除隐瞒，却不会使评价自动中立。一个作者可以完全坦率地说明自己使用了 TNT 复制，观众也可以在不指控其欺骗的同时，认为该成果与无复制存档不宜直接比较。尊重玩法选择，并不要求放弃对资源成本、过程约束和成果可比性的判断。

官方不修，不等于所有争议已经结束

在本文所据的讨论中，有人明确把 “Mojang 没修”“Won't Fix” 和开发者所谓的 “按预期工作” 作为使用争议机制没有问题的证明。这不是无效证据。如果一项问题报告确实被标记为 Won't Fix 或 Works As Intended，开发者曾明确谈及玩家对某种机制的依赖，或者某项行为在多个版本中长期存在，这些材料都会显著增强该机制的实践正当性。在没有相反共同规则的场合，如果官方明确知情并选择保留，再把普通玩家的使用简单描述成 “未经允许的作弊”，就会过于严厉。

但这类主张必须对应到具体证据。在原讨论中，发言者曾经给出过 Mojang 官方链接，但该链接现已遗失，无法放入本文供读者复核。链接遗失并不能反过来证明当时的材料不可靠，但在重新找到它之前，本文也不应让读者无条件接受无法核对的概括。问题跟踪器的状态、某名开发者的发言和社区对发言的概括，不是同一层级的材料；Won't Fix 也不必然与 Works As Intended 同义。如果日后找回链接，应补入报告编号、开发者原话、上下文和适用版本。

“不修” 本身仍然不能承担全部论证。开发者暂不修复某项行为，可能出于开发优先级、兼容旧存档、避免破坏既有机器、社区依赖，或者尚未提供替代机制等多种原因。官方明确选择容忍一种行为，与官方从一开始就把它设计为生产工具，并不是同一件事。即使 Mojang 明确表示会在替代方案出现前保留 TNT 复制，这也首先增强了它在实践中的可接受性，而不会自动要求所有玩家把它纳入自己的严格无复制生存标准。

对官方明知并保留的机制，使用者当然有理由相信自己没有违背一般原版游玩的规则。但一般原版中可以使用，与一个强调常规资源获取的存档是否愿意接受它，仍然是两个问题。前者可以反驳对玩家的道德指控，却不会消除后者对资源边界的选择。

换句话说，“没有被程序阻止” 是一项有关可执行性的事实，“官方暂时容许” 是一项有关维护政策的事实，“某技术服允许使用” 是一项有关共同体规则的事实，“它属于纯生存” 则是一个玩法分类判断。从前三项中的任何一项直接跳到最后一项，都会遗漏中间的标准。

过去有人会用考试作弊未被发现或钻法律漏洞来类比这个问题。这些类比能够表达 “可行不自动等于符合某套规则” 的有限结构，却不能成为决定性证据。考试和法律已经存在外部规则、责任与裁判，而私人沙盒世界未必存在同样的义务。真正稳妥的论证不需要把生电玩家类比成违法者或考场作弊者，只需指出：如果双方正在争论的是某种玩法分类，那么程序是否阻止行为，只是分类依据之一，而不是分类本身。

因此，官方态度可以改变一项机制的使用风险，却不必然改变它的程序成因。一个 bug 可以因为玩家依赖而被长期保留，甚至成为事实上稳定的玩法基础；此时 “已被容忍” 可以为真，“原本就按这个目的设计” 却仍然可以为假。所以，技术玩家可以据此证明自己的使用有充分依据；拒绝非预期机制的玩家也可以继续把程序成因和资源闭环纳入自己的分类。两者争论的已不是 “玩家有没有权利使用”，而是 “使用后应当如何命名”。

长期保留还会产生路径依赖。一项机制最初可能只是一个异常，但玩家围绕它建造机器、教程和整套工程体系后，修复成本就不再等于修改几行代码的成本。官方选择保留它，可能是在承担既有依赖后做出的维护妥协，而不是对最初设计的追认。这种妥协足以让玩家放心使用，却也恰恰说明，“为什么现在不修” 和 “它当初是什么” 不能合并成同一个问题。

因此，对开发者态度的引用也应尽量保留语境。“我们知道玩家在用，现在不修”、“在替代方案出现前保留” 和 “这就是预期的生产方式”，对玩法分类的支持强度并不相同。即使原链接日后被找回，真正值得引用的也不只是一个状态标签，而是官方究竟承诺了什么、没有承诺什么。

“很肝” 能够证明付出，不能替所有机制正名

对生电最不公平的一种指控，是把它描述成按下开关就能空手套白狼。本文所据的讨论详细列出了一个技术存档可能经历的工作：前期下矿获得红石和石英，建立村民交易、刷怪和蜂蜜体系，远距离寻找材料，为世界吞噬者准备机器与沟道，处理流体、黑曜石、基岩缝隙中的残留方块，并在机器运行时持续维护。具体工程的工时会随版本、规模和方案而变，但这些例子足以说明：真实的技术生存远非不劳而获。一个大型技术工程所包含的劳动、知识和协作，完全值得承认。

因此，“生电就是不劳而获” 不是一个可靠的批评。生电玩家说自己前期很肝，并不是虚构辩护；许多技术存档的实际投入，甚至高于普通玩家完成常规生存流程所需的投入。把这种付出一笔抹去，只会暴露批评者并不了解自己正在批评的对象。

然而，“整个项目非常辛苦” 与 “项目中每一种手段都没有改变资源成本” 仍然是两个命题。一个玩家完全可能花费一百小时设计、收集材料和建造机器，同时让这台机器在此后取消某种资源的持续获取成本。前一百小时的艰难证明成果不是白来的，却不能独自回答机器运行时被复制的对象是否本应消耗。

所谓 “高投入、无限回报”，其实包含两种不同的成本。机器建成之前，玩家付出的是选址、材料、设计和建设成本；机器建成之后，产出仍然受运行时间、加载范围、产率、维护和服务器性能限制。刷怪塔并不会在建成瞬间给出无限物品，它只是把原本分散在战斗和寻找中的劳动，改造成了以有限速率持续产出的系统。运行越久，建设成本分摊到每件产品上就越低。这是自动化的一般结构，不是生电独有的异常。

刷怪塔也因此展示了争论的两面。它证明，后期能够长期产出，并不足以把一项机制判为作弊；否则作物农场、铁农场乃至村民交易都会落入同样的指控。可是，“前期很难造” 也不足以为任何后续收益正名。一台需要大量知识和工时的任意物品复制机，仍然可以从根本上取消资源获取过程。真正需要比较的，不是机器有多难造或能运行多久，而是它把哪些投入转化成了哪些产出，保留了哪些持续成本，又绕过了哪些原有的资源关系。

对不希望战斗、探索和手动生产被大量自动化取代的玩家来说，拒绝刷怪塔本身也可以是一种一致的玩法选择。有些服务器还会因为性能、经济或玩法节奏而限制刷怪塔。这些理由可以支持一套事先公开的规则，却不能证明刷怪塔在技术上就是 bug，也不能把其他规则下的使用者直接判为作弊。

“生电玩家最肝，所以后期来财快是他们应得的” 也需要拆开理解。先投入设计、材料和建设，随后取得持续高产，确实是自动化最有力的正当性来源。农场的高效率不是对劳动的否定，而是劳动方式的改变。一个人不应因为坚持手工生产，就断言使用机器的人耍赖。可是，“前期付出过” 也不能推出 “此后任何形式的收益都符合任何规则”。劳动与回报之间仍需有具体的机制关系，不能用搬运蜜蜂的辛苦替 TNT 复制正名，也不能用世吞挖沟的工程量证明任意物品复制合理。

这里必须承认生电玩家提出的高铁类比有一半是成立的。能够骑马从上海到北京，不代表人就不该坐高铁；能够写信，不代表无线通信就是耍赖。同样，能够手挖资源，不代表玩家不该用熔炉、漏斗、村民、刷怪塔和红石系统提高效率。手动不天然高贵，重复劳动也不天然构成更真实的生存。

但这个类比不能包办所有问题。高铁和无线通信是被制度明确提供的成品技术，而复制机制是否属于被正式设计的生产工具，正是争议所在。用高铁类比红石自动化很有说服力，用高铁类比任意物品复制则已经把结论藏进了前提。这个类比足以反驳 “凡自动化皆作弊”，却不能证明 “凡有技术门槛的机制利用皆与自动化等价”。

劳动也不是可以在不同机制之间任意转账的通货。一个玩家为了蜜蜂、红石和世吞沟道付出巨大劳动，可以证明整个工程的难度，却不能把这些劳动自动折算成 “此后可以取消某项消耗” 的资格。不同投入之间是否存在足够紧密的机制联系，比总工时是否惊人更重要。否则，只要复制机本身造得足够昂贵，任意物品复制也可以被说成对前期劳动的回报。

刷怪塔与 TNT 复制也不必只用 “都能持续产出” 来比较。刷怪塔通过控制生成空间、击杀方式和玩家位置，把刷怪时间转化为特定掉落物；TNT 复制则在不反复消耗 TNT 的情况下反复产生爆破效果。前者可以被理解为把正常生成规则工业化，后者则更直接地改变了一次爆破与一块 TNT 之间的消耗关系。这不能自动证明刷怪塔就应被所有服务器接受，却说明了为什么一个人可以在不自相矛盾的情况下接受刷怪塔而拒绝 TNT 复制。

反过来，若有人认为自动刷怪本身就过度削弱了战斗和探索，他也可以同时拒绝刷怪塔和复制机制。这种规则比技术社区更严格，但并不因此没有逻辑。只要它事先公开，并对熟人、新人和不同形式的机器一致适用，它就是服务器定位的一部分，而不是必须向技术玩家证明自己 “懂游戏” 后才能存在的例外。

效率需求揭示设计缺口，却不自动证明手段合理

Minecraft 的后期确实可能令人感到 “坐牢”。当玩家开始建设大型空置域、交通网络、工业区或超大规模建筑时，原版的批量采掘与资源供应能力未必匹配他们的工程目标。TNT 的常规制造需要沙子与火药，而沙子的常规大量获取往往依赖寻找和开采；即使使用鞘翅和信标，大规模清理地形仍可能充满重复劳动。技术社区广泛使用 TNT 复制完成爆破，可以被解释为游戏存在后期工具缺口的重要迹象，但这仍是一项关于玩家需求的推论，而不是仅凭使用人数即可证明的设计事实。

对于世界吞噬者这类需要持续自动爆破的超大型工程，TNT 复制可能确实是目前唯一现实的方案。这能解释技术社区为什么保留它，也能说明简单修复为什么会使一整类工程失去可行性。但 “工程只能依赖这项机制完成” 与 “这项机制因此符合所有生存标准” 并不是一回事。缺少超大规模工具，可以被看作需要弥补的设计缺口，也可以被看作游戏对工程规模留下的边界。玩家选择清空巨量区块的目标，并不会因此自动要求其他玩法为这个目标改变资源规则。

这一点值得被严肃对待。一个机制被大量玩家长期依赖，不应只被一句 “这是 bug，修掉就好” 打发。粗暴修复可能摧毁已有工程，也可能让一整类玩法在没有替代方案的情况下失去可行性。若 Mojang 希望减少玩家对复制机制的依赖，更合理的做法或许是提供昂贵但可再生、能够规模化部署的正式爆破或采掘方案。

然而，设计缺口能够解释一种机制为什么流行，也能支持官方暂时保留它，却仍不能自动证明它符合所有人的纯生存定义。一个工程只有在允许某项机制时才具有现实可行性，首先说明该工程依赖这套规则。玩家可以据此主张 “我们的技术生存允许 TNT 复制，因为没有合理替代”，但不能省略前半句话，只留下 “所以 TNT 复制当然是纯生存”。

工程目标本身也并非外部强加给玩家的义务。一个人决定清空巨量区块、制造极端产能或建造超大工程，是在选择一种游戏目标。目标宏大值得钦佩，却不能反过来要求所有生存标准都为它修改。严格无复制生存玩家可以选择缩小工程、延长工期或放弃项目；技术玩家也可以选择允许复制以实现目标。两者的差别不在谁更能吃苦，而在于他们愿意保留哪些约束。

所以，评价效率提升不能只看产量。通过一次性建设和长期维护换取自动产出，通过深层机制优化流程，以及直接复制资源或保留本应消耗的对象，都可能具有技术含量，却对生存约束产生不同影响。“捷径” 也不等于 “轻松”：一条路线可能极难建成，却在建成后显著缩短另一项流程。严谨的批评应当指出究竟取消了哪一项成本，而不是用 “捷径” 两个字否定整项工程。

“没有替代方法” 也不必然意味着游戏欠玩家一种替代方法。某些工程在常规规则下无法以合理工期完成，既可以推动玩家发明新技术、呼吁官方增加工具，也可以使人重新考虑工程的必要性和规模。游戏中的成本不只是妨碍创造的噪音，它也会影响什么值得建、建多大、先建什么。如果每当一个宏大目标遇到成本上限时，都用目标的宏大反过来证明应当放宽手段，那么生存约束就只会在它尚未阻碍玩家时才被承认。

这并不是要求技术玩家放弃世界吞噬者，而是说明两套玩法对 “目标与限制谁应该迁就谁” 给出了不同答案。技术生存更愿意为了扩展可实现的工程而纳入稳定、可控的争议机制；严格无复制生存则更愿意让工程目标服从已经选定的资源边界。前者不是偷懒，后者也不是拒绝进步。

真正需要警惕的是变化的评价标准

围绕 “特性”“bug”“技术” 和 “作弊” 的争论，首先需要警惕的并不是玩家采用了某项机制，而是明示的辩护理由与实际的区分标准并不一致。如果 “原版能做” 只在支持某些机制时被当成决定性理由，在拒绝其他机制时却又不再有效，那么真正起作用的标准就还没有被说出来。

当然，这种差别并不必然构成双重标准。不同漏洞的影响原本就不同。TNT 复制可能主要提供爆破能力，任意物品复制则可能摧毁整个资源体系；更新抑制可能服务特殊工程，另一种漏洞则可能严重影响服务器稳定性。玩家完全可以依据复制对象、成本变化、性能影响和共同规则，对不同机制给出不同评价。

更有甚者，评价标准还可能随着利益变化：对自己的工程有利时，长期未修被解释成官方认可，非预期行为被解释成技术深度；当另一项漏洞破坏服务器经济、影响自己的体验或使别人的收益过高时，论证又可能立刻变成 “它显然违反设计意图，所以应该修”。无论是否能进一步判断其动机，双重标准都出现于评价依据不再一致的时候。如果一个人接受 TNT 复制的理由是 “原版能做，所以不算作弊”，那么面对其他原版可执行的复制漏洞时，他不能只凭 “不喜欢” 就更换标准；他需要说明两者在影响、规则或官方态度上的差异。如果一个服务器禁止某种机器是为了性能，那么限制也应尽可能针对实体数量、区块加载或实际负载，而不是只对不熟悉的建筑使用模糊的 “禁止生电”。

同样，“大服务器都无所谓，只有小服务器服小事多” 并不能回答规则是否合理。服务器是否允许某种机制，取决于定位、性能、经济系统、公平目标、玩家构成和管理能力。大型技术服允许复制或世吞，只能证明这些机制适合它们的目标；生存服、经济服或休闲服禁止它们，也可能有充分理由。一套规则是否值得接受，应当看它是否事前公开、稳定适用、与服务器目标一致，并让玩家能够知情选择，而不是看服务器规模能否提供身份背书。

还有一种辩护会把机器拆解成一连串普通操作：在天上造房子很正常，不插火把很正常，修一条上下通道也很正常；养一只末影螨很正常，给它保护也很正常，所以刷怪塔和小黑塔当然无从禁止。这种说法准确指出，复杂机器通常由合法的局部操作组成。但局部操作都常见，并不意味着组合后的系统不能成为规则对象。反过来说，如果服务器只写一句 “禁止刷怪塔”，却不给出识别标准、性能理由和处罚边界，那么管理规则也确实过于含混，容易造成选择性执法。好的规则应直接说明它限制的是产量、实体数量、加载方式、复制行为还是性能影响，而不是迫使双方玩文字拆解游戏。

此外，所有判断都应注明版本与运行环境。Java 版和基岩版的机制并不完全相同，不同版本会修复、改变或新增行为，服务端实现、性能模组和规则插件也可能改变原版结果。一个机制在某个 Java 版本的技术服中被接受，不能不加说明地推广到所有版本和平台；服务器对某种机器的限制，也可能针对服务端负载而不是对玩家技术作价值判断。脱离版本和环境谈 “原版机制”，很容易让双方其实在讨论不同对象。

如果一个人对 TNT 复制、沙子复制和任意物品复制都采用 “不主动利用明显非预期的资源断裂” 这一标准，那么他对 TNT 复制的拒绝就不是因为不懂其工程用途，而是对同一原则的延续。这套原则不一定能轻松处理所有边界案例：刷怪塔、村民交易和各类状态机制究竟是重组正常规则，还是实质上绕过了资源成本，仍然可以继续争论。但有边界争议，不等于这条原则没有内容；正如技术社区会给不同复制机制划分层级，严格无复制生存也可以形成自己稳定的判断传统。

规则可以不同，评价必须具体

写到这里，我的结论并不是 “生电不配叫生存”，更不是 “生电玩家都在作弊”。生电内部不存在统一的机制清单。有人只使用普通自动化，有人接受 TNT 复制但拒绝任意物品复制，有人研究更新抑制，也有人采用更宽松的漏洞规则。评价必须落到具体机制、具体服务器和具体承诺上，而不能把 “生电玩家” 当作一个整齐划一的对象。

严格无复制生存的价值也不只是愿意投入更多重复劳动。它有意保留资源的获取、消耗、风险和工程规模之间的关系，也为不同存档的成果提供一种较容易识别的共同基准。拒绝复制机制，可以是对想保留何种游戏结构的清楚选择，而不是对技术的无知。但它也不因此天然高于技术生存。机器的设计、建设与维护本身同样是一种玩法能力；批评漏洞正名，不应退化成对效率、自动化或工程能力的敌意。

我反对的只是话语排他：生电不应被宣布为唯一高级的玩法，手动生存也不应被宣布为唯一真实的生存；技术玩家不应把拒绝某些漏洞的人一概称为不懂游戏，严格无复制生存玩家也不应把规则公开的技术服一概判为作弊服。不同共同体可以对 “纯生存” 有不同用法，但当这个标签被用于比较成果时，最好附带更精确的规则说明。

“原版技术生存，允许 TNT 复制”“允许世吞与更新抑制，禁止任意物品复制”“严格无复制生存”，这些表达并不复杂，却比单独争夺 “纯生存” 三个字提供了更多信息。它们不会贬低任何成果，反而让观看者知道自己正在欣赏什么：是受持续资源约束的长期积累，是对底层机制的高强度开发，还是在特定规则下实现的大型工程。

生电可以玩，也值得研究；严格无复制生存可以拒绝复制及依赖复制机制的世吞方案；服务器可以根据性能、经济与定位制定自己的边界。官方默许、社区流行、前期劳动和后期效率，都能成为讨论某项机制是否可接受的理由，却没有任何一项能够单独终结讨论。

玩法自由与规则清晰本来就可以同时成立。真正成熟的沙盒文化，不需要每一种玩法争夺唯一的正统名称，也不需要把不同选择排列成高低贵贱。使用什么机制，就在需要比较与协作时说明什么机制；采用什么边界，就让参与者知道什么边界。如此一来，技术不必伪装成苦行，严格也不必转化为优越，而每一种成果都能在自己的规则中得到准确的理解。

争议速查表

%&!@&#%^&*#%

引用 Wikipedia:Please be a giant dick, so we can ban you。讨论请得体，切勿在边缘试探，挑战一个人的底线。

课内成绩是基本盘

客观地说，学习竞赛确实会占用一部分课内学习时间，因此一定要在课内成绩和竞赛学习之间做好平衡。如果你对自己的课内成绩没有足够把握，那么在学习竞赛的过程中，很可能会因为课内成绩下滑而面临被调整出实验班的风险，进而被迫中止竞赛学习。所以，无论你学习竞赛是为了升学、兴趣，还是为了挑战自己，也无论你现在的竞赛水平如何、目标成绩如何，只要你想把竞赛长期学下去，首先要做的事情就是稳住课内成绩。课内成绩是你继续学习竞赛的基本保障，也是你在学校环境中获得稳定学习资源和时间安排的基础。

当然，“稳住课内成绩” 并不意味着你必须把所有课内科目都学到极致，而是要保证自己不因为课内学习出现明显短板而影响整体规划。竞赛学习本身就是一件需要长期投入的事情，如果课内成绩一直处于危险状态，你就很难安心投入竞赛。比较理想的状态是：课内成绩保持在一个相对安全的位置，竞赛学习再逐步推进。这样即使某段时间竞赛训练强度较大，也不至于让课内成绩崩盘。

心态与预期

学习竞赛新知识的时候，往往会觉得很有意思，因为它比课内内容更深入，也更有挑战性。但你也要提前意识到，高中阶段任何一门学科的复习过程都可能是枯燥的，竞赛也一样。刚开始学新内容时，可能会有明显的新鲜感和成就感；但到了复习阶段，你会反复面对大量细节、错题、笔记和记忆内容，这个过程并不轻松。学习竞赛同样会遇到瓶颈期、进步停滞、状态波动、考试失误等问题，这些都是正常现象，不代表你不适合学竞赛。

在遇到这些问题时，竞赛老师通常能够在知识体系、学习方向和训练安排上给予比较专业的指导，也往往比较了解竞赛生常见的学习状态。不过，关于学业规划、时间分配、心理压力等问题，你也可以多向几类可靠的人请教，比如班主任、任课老师、学长学姐、家长，或者有经验的竞赛教练。不同的人能提供不同角度的建议，综合参考后，你会更容易做出适合自己的判断。不要因为一时学不动、考不好，或者觉得进度落后，就轻易否定自己；但也不要盲目硬撑，完全不管课内成绩和身体状态。

笔记与量化目标

关于我个人的经验，我曾经给自己设定过一个心理暗示：每认真整理一页高质量笔记，就相当于让自己提高 0.1 分。比如，如果你现在大约能考 50 分，目标是冲到 90 分并争取省一，那么可以尝试整理 400 页左右高质量、较详细的笔记，并在联赛前尽量背熟其中的 300 到 350 页。当然，这个数字不是严格标准，也不是真的说 “一页笔记必然对应 0.1 分”，它更像是一种量化目标和自我激励方式。不同人的笔记密度不同，我的笔记比较稀疏，所以一页大概按 0.1 分来估算；如果你的纸张较大、字比较小、内容写得比较密，也可以给自己设定为每页对应 0.5 分甚至 1 分。关键不在于数字本身，而在于通过整理、复习和背诵，把知识真正内化成自己的体系。

记忆与整理

之所以建议重视笔记，是因为生物竞赛对记忆、整理和归纳能力的要求很高，尤其是动物学、植物学、动物生理学、植物生理学等内容，需要掌握大量细节。如果只是反复看课本，而不进行系统整理；或者整理了笔记却放在那里不复习、不背诵，那么这些部分的分数就很难稳定拿到。比较有效的做法是：第一遍学习时先建立框架，知道每一章大致在讲什么；第二遍复习时补充细节，把容易混淆的概念、重要结构、典型过程整理出来；第三遍则要围绕题目和错题查漏补缺，把那些自己总是忘、总是错的内容单独标记出来。笔记不一定要追求好看，但一定要方便自己复习，最好能做到 “看一眼就知道重点在哪里”。

关注冷门知识

此外，生物竞赛不像课内考试那样有非常明确、稳定的课程标准或考试范围，出题内容可能会比较灵活。有些知识点过去很少考，但一旦出现在试卷中，如果你之前看过，就有可能做出来；如果完全没接触过，可能连蒙都没法蒙。比如一些较少见的图表、实验技术、生理现象、分类学细节或者生物学史相关内容，都可能成为考点。因此，到了复习中后期，当课本上的主干知识已经复习得差不多时，一方面要继续巩固核心内容，另一方面也不要完全忽略那些相对冷门、细碎的知识点。这些内容往往是后期进一步拔高的关键。主流知识点决定你的基础分，细节和冷门知识则可能决定你能否拉开差距。

复习方法

在具体复习时，建议不要只看书，也不要只刷题。只看书容易产生 “我都会了” 的错觉，但一做题就发现细节记不清；只刷题则可能导致知识体系零散，遇到新题时不会迁移。比较稳妥的方式是把教材、笔记和题目结合起来：先用教材和老师讲义建立体系，再用题目检验掌握程度，最后把错题中暴露出的漏洞补回笔记里。（关于这个 “补回”，我的做法是第一次记笔记记单页，也就是只用正面，反面可以用来补漏，或者记一些题里新学到的知识点。）尤其是生物竞赛，很多题目并不是单纯考你背没背，而是考你能不能把多个知识点联系起来，比如把细胞生物学、遗传学、生理学和实验设计结合在一起。因此，复习时要有意识地训练自己从 “记住知识” 过渡到 “使用知识”。

善用 AI 工具

现在 AI 工具发展很快，也可以适当利用 AI 辅助学习。生物竞赛涉及生物学的多个分支，内容非常广，任何一个人都很难对所有细节都随时给出完整回答。所以，当你遇到一些教材讲得不够清楚、网上资料比较分散，或者自己暂时找不到系统整理的问题时，可以尝试向 AI 提问，让它帮助你建立框架、解释概念、整理表格或生成复习提纲。比如你可以这样问：“请告诉我关于各种 PCR 技术的知识，包括它们的中文名称、英文全称、英文缩写、基本操作方法、应用范围和主要特点，请尽可能全面、系统地整理。” 得到回答后，不要直接照抄，最好自己再筛选、核对和提炼，把真正重要的内容整理进笔记本。这样既可以当作知识字典，也可以作为背诵提纲。

不过，使用 AI 时一定要注意核查。AI 很适合帮你整理思路、提供框架、解释概念，但它并不总是准确，尤其是在一些细节性、专业性很强的问题上，可能会出现看起来很合理但实际上不严谨甚至错误的回答。因此，比较重要的知识点最好结合教材、权威资料、老师讲解和多个来源进行交叉验证。你可以让 AI 给出参考来源，也可以让它对同一个问题从不同角度解释，但最终写进笔记、用于考试的内容，一定要经过自己的判断和核对。AI 是工具，不是标准答案。

长期主义

最后还想补充一点：学习竞赛需要长期主义。不要指望短时间内靠突击完成质变，也不要因为一次考试成绩不好就觉得前面的努力都没有意义。竞赛成绩的提升往往不是线性的，可能很长一段时间看起来没有进步，但当你的知识体系、题感和记忆量积累到一定程度后，分数会突然上一个台阶。真正重要的是，你能不能持续稳定地学习，能不能及时复盘自己的问题，能不能在课内和竞赛之间找到适合自己的节奏。只要方向正确、方法不断调整、基础持续积累，后期的提升空间是很大的。

以上就是我关于生物竞赛学习的一些经验和想法。每个人的情况不同，适合自己的方法才是最好的方法。祝大家都能在竞赛中取得满意的成绩。

性价比才是杀伤力

GPT 当然还会有人买，就像劳斯莱斯当然还会有人买。但如果有车企能用 1/6 的价格做出 90% 的劳斯莱斯体验，那绝大多数人不会再把劳斯莱斯当默认选择。

相似的，GPT 会从 “主流默认模型” 变成 “高端兜底模型、品牌保险模型、特殊场景模型”。而 GLM 这种模型真正的杀伤力在于：它让用户开始认真计算 “我到底有没有必要为最后那 10% 多付 6 倍价格”。

换句话说，GLM 这类模型打的不是 GPT 的技术，而是 GPT 的价格体系和定价权。GLM 不一定非要全面超过 GPT。它只要做到绝大多数任务够用，价格显著更低，迁移足够简单，就已经能重构市场。

这和安卓手机、国产新能源车、云计算价格战、开源数据库替代商业数据库的逻辑很像。不是说高端品牌马上消失，而是高端品牌还在，但大众市场被更高性价比方案吃掉；同时，高端品牌必须不断证明自己 “贵得有道理”。

但是也不是说高端品牌必须得降价，他们也可以缩减客户群体。就像劳斯莱斯主要是富人在买，也依然不输大众车企。

用户不为研发账单买单

此外，我想说，OpenAI 的成本压力大，只能说它有动机维持高价，甚至可以说有理由维持高价，但是没理由让客户接受高价。能够让客户接受的理由，可以是性价比，也可以是不可替代的能力，但不是研发投入大。用户没有义务为 OpenAI 的研发成本买单。用户买的是可感知价值，不是厂商的研发账单。

发明者不一定永远拥有最高利润。发明者也没理由永远拥有最高利润。IBM 开创大型机时代，但后来被云分流；奢侈酒店存在，但快捷酒店和民宿服务了大多数需求；特斯拉开创智能电动车潮流，但中国新能源车迅速拉低价格锚点。没有人为 IBM 或者特斯拉说情，因为他们是企业，企业没有维护住自己的市场，纯纯自取。

所以说，OpenAI 的高投入值得尊重，但不自动等于高价格合理。高价格是否合理，取决于这些投入是否转化成用户愿意付费的、竞品无法替代的增量价值。

别跟我谈情怀

如果说 OpenAI 是科研机构，我会因为 “为人类作贡献” 而尊重但不购买。但是他们已经说过自己不是公益机构，那么我就要骂而且不购买了。既然你想赚我的钱，那就别跟我谈 “改变人类未来” 的情怀。大家打开天窗说亮话，按商品契约来谈——你的 Token 凭什么这么贵？你的功能多出来的 10% 值不值那 6 倍的差价？如果你拿不出对得起这个价格的绝对代差，还想让用户承担你高昂的 “大厂研发公摊成本”，那就别怪用户不仅不买账，还要在走的时候啐一口。

过去，我们谈大模型必谈 AGI 信仰、谈算力奇点、谈人类未来；现在，我们已经在谈投资回报率、Token 单价、迁移成本、算力功耗比。AI 已经是市场 + 科研的混合物，忽略市场空谈理念和科技必然是错误的。

互联网没有记忆，但资本和用户的钱包有。OpenAI 最大的尴尬在于，它用最资本主义的方式撕毁了最初的公益宿命，现在却指望用户用最理想主义的情怀去包容它的高昂溢价。这世界上哪有这么便宜的事。既然进了商场做买卖，就得老老实实遵循价格战的世俗规律，被性价比更高的竞品 “掀翻桌子”，真的纯属自取。

说到底，技术值得尊重，但价格只认市场。谁能用更低的成本解决同样的问题，用户就会用脚投票。这个道理，古今中外概莫能外。

若从软件工业、系统工程、安全工程、语言生态和个人职业发展的角度来看，事情远比 “取代” 或 “不会取代” 复杂。更准确的问题并不是 Rust 会不会让 C 和 C++ 消失，因为两者背后有数十年的存量代码，以及操作系统、数据库、浏览器、游戏引擎、嵌入式、音视频、图形、科学计算、工业软件、金融系统、芯片 SDK、驱动和基础库。真正值得问的是：未来新项目立项时，C 和 C++ 是否仍是默认首选？Rust 能否让原本会使用 C/C++ 的新系统项目转向？哪些领域会被分流，哪些地方即使抛开历史原因也很难被分流？作为 C++ 开发者，又该如何面对这种变化？本文围绕这些问题展开。

Rust 的目标不是让 C/C++ 消失

很多关于 Rust 的争论，一开始就偏离了重点。有人认为 Rust 不可能取代 C/C++，因为 Linux、Windows、OpenSSL、ffmpeg、LLVM、Unreal、Chrome、数据库和嵌入式系统都不会重写。这没有问题。但更现实的目标，并不是将所有 C/C++ 存量系统重写一遍，而是减少 C 和 C++ 在新增项目中的默认地位，让未来更多系统工程的新项目不再首先选择它们。

过去，项目的语言选择往往遵循一条熟悉的路径：追求性能时选 C++，需要底层控制或贴近硬件时选 C，需要操作系统组件、驱动、数据库、存储或网络栈时选 C/C++，不想引入 GC 时也常常选 C++。Rust 想改变的正是这条默认链条。它并不是说 C/C++ 会在明天消失，而是在问：如果今天从零开始编写一个系统组件，尤其是安全敏感、面向网络或处理不可信输入的组件，为什么还要默认选择 C/C++？当行业心智从 “系统项目默认 C/C++，除非有理由不用”，转为 “系统项目先考虑 Rust，除非有理由必须使用 C/C++”，Rust 在新增项目上的目标便已实现。因此，这场竞争并不是消灭存量，而是争夺新增。

成熟资产和新项目不是一回事

安全领域很能说明成熟资产与新项目的差别。仅因 Rust 具有内存安全特性，就断言 OpenSSL 应被 rustls 替代，并不足以构成完整判断。选择 TLS 库时，语言只是其中一项因素；项目负责人还会考察它经历过多少真实攻击与多年审计，是否支持各种平台并能与客户端、服务器和证书系统互操作，是否具备合规认证路径、漏洞响应机制和长期维护者，以及它是否已在银行、云厂商、浏览器、操作系统和大型企业的真实环境中部署过。出问题时由谁负责，同样是选择的一部分。

OpenSSL 虽然以 C 编写，也出现过严重漏洞，但它被攻击、审计、修复和大规模部署过，并在各种输入与环境中积累了经验。年轻的 Rust TLS 库即便内存安全特性更强，也不自动意味着整体安全风险更低。TLS 库还涉及协议状态机、证书链和 X.509 解析、密码套件选择、降级与重放防护、随机数使用、常数时间实现、侧信道、API 易用性、平台兼容、硬件加速、合规认证、长期审计、供应链和真实世界互操作性。Rust 主要处理语言层面的内存安全，不能自动保证这些方面没有漏洞，也不能立即补足十几二十年的审计信用。

因此，把成熟稳定的 OpenSSL 换成一个年轻 Rust 库，并不会只因 “Rust 更安全” 就成为必然选择。但从零编写新的安全组件时，情况会不同。证书、图片、字体、压缩格式和网络协议解析器，以及 sandbox 边界、WebAssembly runtime、身份认证网关、密钥管理、安全扫描、边界代理、VPN 和新协议栈，都需要处理大量不可信输入。此时继续选择更容易出现 use-after-free、buffer overflow、double free、越界访问和数据竞争的语言，需要给出明确理由。更准确地说，OpenSSL 未必会被 rustls 替代，但新的同类安全资产未必还会以 C 为默认实现语言。

Rust 的内存安全是否已经足够重要

也应避免把 Rust 的安全能力说得过满。Rust 在语言层面主要解决内存安全和一部分并发安全问题，例如 use-after-free、double free、buffer overflow、越界读写、悬垂指针、迭代器失效、部分未初始化内存、数据竞争和资源生命周期混乱。这些确实是 C/C++ 安全漏洞中的重要来源，浏览器、操作系统和网络服务中的许多高危漏洞都与它们有关。

但 Rust 不会自动解决密码算法、协议设计、认证流程、证书验证、权限模型和状态机的正确性，也不能保证常数时间实现、侧信道防护、供应链安全、依赖治理、API 设计、系统配置、运维、合规和审计。因此，说 Rust 主要解决内存安全，大体上是成立的。与此同时，Option、Result、enum、模式匹配、所有权、借用、移动语义、trait 和类型状态建模，确实能减少一部分安全工程错误。它们可以区分已验证与未验证的证书，限制握手前后的状态混用，避免明文密钥被任意复制，并把资源释放、跨线程共享、错误处理和权限 token 的使用方式表达得更明确。

这些能力并不等同于密码学正确性，但属于安全工程的一部分。Rust 不能自动让安全组件正确，却能使许多危险错误无法通过编译，并帮助开发者明确安全状态和资源边界。面对 OpenSSL、BoringSSL、LibreSSL、libsodium 等成熟项目，年轻 Rust 库的这些优势也未必能压过长期部署和审计形成的信用。更可能的情况是，成熟的 C/C++ 安全基础设施继续存在；新增安全边界组件更多考虑 Rust、Go、Java、C# 等内存安全语言；关键密码库仍需经过长期部署、审计、攻击和修复，才能建立信用。

为什么很多语言挑战 C/C++ 失败？

C/C++ 难以被挑战，并不是因为它们没有缺点。内存安全、UB、构建系统、包管理、C++ 的语言复杂度、模板报错、ABI 和大型工程维护，长期都是实际问题，安全漏洞的代价也很高。但它们同时具备一组少见的能力：性能可以接近硬件上限，没有 GC，资源控制相对可预测，能够操作内存布局并贴近 ABI，也能用于操作系统、驱动、数据库、浏览器、游戏引擎、裸机和嵌入式环境。C ABI 是事实上的跨语言接口标准，平台支持广泛，存量和生态庞大，调试器、profiler、sanitizer 与编译器工具链也已经成熟。

因此，挑战 C/C++ 的语言不能只说明自己更安全或更易写，还必须回答一系列工程问题：是否有 GC，能否用于裸机和内核，能否控制内存布局并与 C ABI 交互，性能能否接近 C/C++，资源释放是否可预测，能否渐进迁移，工具链是否足以支撑大型工程，以及大型组织是否愿意采用。历史上的许多语言都没有同时回答好这些问题。

Java 和 C#

Java 和 C# 都取得了广泛采用，承接了大量原本可能由 C++ 编写的企业、服务器、桌面和平台应用，但没有真正取代 C/C++ 的系统编程位置。两者都有 GC 和运行时，不适合裸机、内核、驱动或硬实时场景；内存布局的控制也不够直接，ABI 与硬件之间隔着一层，延迟和资源释放并不完全由程序员直接决定。这并非否定 Java 或 C#，而是说明它们主要覆盖应用层和企业层，对 C++ 的影响是局部的。

Go

Go 在云原生、网络服务、平台工程和基础设施工具中也很成功。Docker、Kubernetes、Prometheus、etcd 和 Terraform 等生态使它有了广泛影响力。其简洁的语言设计、较快的编译速度、方便部署、goroutine、标准库和较为一致的工程体验，吸引了许多团队；不少原本可能用 C++ 编写的服务端基础设施项目因此转向 Go。

不过 Go 仍有边界。它带有 GC，底层控制力弱于 C/C++/Rust，类型系统相对保守，也不适合内核、驱动、裸机、极端低延迟和大量依赖精细内存布局的项目。它的性能足以覆盖许多场景，但并不追求 C/C++ 的极限模型。因此，Go 更接近面向云基础设施的简化选择，而不是 C++ 的直接替身。

D

D 语言曾经非常像 “更好的 C++”。它有：系统编程能力；高性能；现代语法；模板；可选 GC；C 互操作。但 D 没有成为主流。原因包括：生态没有起来；标准库和编译器路线分裂；社区规模有限；企业背书不足；没有形成不可替代的核心叙事；C11 之后 C 自己吸收了一部分现代特性；没有像 Rust 那样抓住 “内存安全” 这个政策级、组织级驱动力。D 是一个典型例子：技术上很有野心，但没有形成产业势能。

Ada/SPARK

Ada 和 SPARK 在高可靠领域非常强。它们适合：航空航天；军工；高可靠系统；需要形式化验证的项目。但它们没有成为通用系统编程主流。原因包括：社区小；工具链和生态相对封闭；普通互联网公司采用少；学习和行业门槛高；开源世界存在感有限；语言形象偏专用、高可靠、政府 / 军工。Ada 是局部成功，但不是广义替代。

Swift

Swift 很现代，也有不错性能。但它主要成功在 Apple 生态。它的问题是：心智上绑定 Apple；Linux/服务器/嵌入式/内核生态弱；系统编程社区心智不如 Rust；没有形成 “C/C++ 安全替代者” 的强叙事。Swift 是成功语言，但不是广义 C/C++ 挑战者。

Zig

Zig 是值得关注的语言。它强调简洁、无 GC 和显式控制，C 互操作与交叉编译体验较好，也适合底层、小系统和工具链场景；相较 Rust，其学习曲线通常更平缓。两者的差异在于，Zig 更接近现代化的 C，而 Rust 更强调内存安全的系统编程。Zig 没有 Rust 那样的强所有权和借用模型，也没有将内存安全作为核心叙事。因此，它可能会进入一部分希望获得更现代工具链与表达方式的 C 场景，但未必取代 Rust 在内存安全系统工程中的定位。

Rust 为什么特殊？

Rust 之所以被认为是 C/C++ 的强力挑战者，不是因为它语法时髦，也不是因为它社区热闹，而是因为它第一次比较完整地回答了系统程序员最在意的几个问题。

Rust 没有 GC

这是关键。GC 并非没有价值，它适合大量应用开发；但对内核、驱动、bootloader、部分嵌入式和硬实时系统、低延迟交易系统、游戏引擎关键路径、数据库存储引擎、密码库和基础库而言，额外运行时与不可直接控制的回收行为都可能成为限制。系统 runtime 本身也难以依赖另一个复杂 runtime。Rust 的特殊之处在于，它不依靠 GC 管理内存，而是在编译期尽量证明内存使用合法，因此能够进入 C/C++ 长期覆盖的核心场景。

Rust 保留了系统编程能力

Rust 能完成许多传统 C/C++ 所承担的工作，包括控制内存分配、区分栈与堆、使用自定义 allocator、零成本抽象、指针操作、SIMD、FFI、no_std、裸机和嵌入式开发，以及操作系统组件、驱动、WebAssembly runtime、数据库、编译器和网络栈。许多底层操作仍需使用 unsafe，但其思路是将不可避免的危险操作限制在明确的边界内，让安全代码成为默认。相比之下，C/C++ 的更大一部分语言空间都可能出现不安全操作；这种边界差异对大型团队和安全审计有实际影响。

Rust 攻击的是结构性问题

C/C++ 的内存安全问题不能只依靠开发者更谨慎来解决。静态分析、code review、sanitizers、fuzzing、RAII、smart pointers、Core Guidelines、现代 C++、编码规范、安全子集和生命周期分析都很有用，却没有从根本改变语言模型：悬垂指针、越界访问、重复释放、错误别名、UB 和并发数据竞争仍可能出现。Rust 的吸引力在于，它不只是要求程序员更加小心，而是让大量错误无法通过编译。这也解释了为什么企业、安全团队和政府机构越来越重视内存安全语言；这一政策与产业背景，是以往的挑战者并未同时具备的条件。

Rust 可以渐进进入 C/C++ 系统

Rust 不需要你一次性重写几百万行 C++。它可以走现实路线：老核心继续 C/C++；新模块用 Rust；新解析器用 Rust；新安全边界组件用 Rust；新 CLI 工具用 Rust；新存储组件用 Rust；新网络代理用 Rust；通过 FFI 和原系统连接；慢慢扩大 Rust 代码比例。这就是 Rust 最危险的地方。它不需要马上替换整个系统。它只需要在每一次新增模块时赢一点点。长期看，新增项目份额就会变化。

Cargo 和工具链体验是巨大优势

C/C++ 的工程体验长期很痛苦：Makefile；CMake；Autotools；Bazel；vcpkg；Conan；系统包管理器；平台 SDK；编译器差异；链接问题；ABI 问题；依赖版本问题；跨平台构建问题。C++ 程序员往往已经习惯痛苦了，但新团队、新项目、新人并不一定愿意继续承受。Rust 的 Cargo、crates.io、rustup、rustfmt、clippy、测试、文档生成这一整套工具链，对于新项目吸引力很强。Rust 不只是语言安全，它的现代工程体验也在分流 C++。

Rust 会不会被 “程咬金” 截胡？

可能。Rust 不是终点，也不是完美语言。它有很多现实问题：学习曲线陡；borrow checker 难；生命周期让新人崩溃；编译速度慢；async 复杂；trait/generic 系统有时过于绕；宏系统强但复杂；unsafe 仍然不可避免；C++ 互操作不够自然；ABI 稳定性不足；某些领域生态薄弱；crate 依赖树和供应链治理有风险。所以未来出现一个新语言，说：我有 Rust 的无 GC、性能和内存安全，但语法更简单、编译更快、异步更自然、C++ 互操作更好。这是完全可能的。潜在 “程咬金” 有几类。

Zig

Zig 可能会在一些 C 的生态位上成功。它简洁、直接、无 GC、C 互操作强、交叉编译体验好。但 Zig 不以强内存安全作为核心卖点。所以它更可能成为：

更现代、更舒服、更工程化的 C。而不是全面取代 Rust 的安全系统语言。

Carbon / Cpp2

Carbon 和 Cpp2 这类东西，本质上想给 C++ 找一条现代化迁移路线。如果它们能做到：与 C++ 无缝互操作；迁移成本低；性能保持；工具链成熟；大厂支持；安全性显著提升；保留 C++ 生态资产。那它们会对 Rust 形成很大威胁。因为很多公司最大的问题不是 “Rust 好不好”，而是：我已经有 500 万行 C++，怎么办？如果有一种语言能作为 C++ 的自然继承者，并且迁移成本远低于 Rust，那它当然有吸引力。但目前看，这条路还非常不确定。C++ 的历史包袱太重。要在保留兼容性的同时显著改善内存安全，极其困难。

Mojo

Mojo 更偏 AI、高性能计算、Python 生态加速。它如果成功，可能会影响：AI 基础设施；数值计算；GPU kernel；Python 性能扩展；高性能计算。Mojo 未必正面替代 Rust，而可能直接吃掉一些 Rust 本来可能进入的 AI/HPC 新领域。

安全 C++

C++ 社区不是什么都不做。未来可能会有：lifetime profile；safety profiles；静态分析强化；sanitizers 常态化；C++ Core Guidelines；编译器强制安全模式；受限 C++ 子集；Herb Sutter 的 Cppfront/Cpp2；Google、Microsoft 等推动安全 C++。如果 C++ 能在不破坏生态的情况下显著降低内存安全风险，Rust 的上升速度会受影响。但这很难。因为 C++ 最大的问题是兼容性。它不能轻易禁止大量历史写法。它的自由和混乱是同一个硬币的两面。

但 Rust 不会被 “突然” 截胡

即使未来出现更好的语言，Rust 也不会突然消失。语言生态变化很慢。一个新语言要经历：

爱好者使用；小工具验证；中型项目采用；大公司试点；工具链成熟；生态形成；招聘市场出现；关键基础设施采用；安全审计和长期部署积累；形成产业信任。这个周期通常是 5 到 15 年。Rust 现在已经不是玩具语言。它已经进入：

Linux kernel；Android；Windows 的部分安全讨论和组件；AWS；Cloudflare；Google；Microsoft；Mozilla；WebAssembly 生态；Firecracker；Wasmtime；TiKV；Vector；Deno；Ruff；uv；SWC；ripgrep；fd；bat；starship；Zed 等工具和项目。Rust 已经占住了一个很强的心智：Rust = memory safety + no GC + systems programming + performance + C/C++ alternative。后来者要赢，不能只是更好一点，必须好很多，并且还要花十年级别积累信任。所以更可能的未来不是 Rust 被某个语言一击打倒，而是：Rust 还没完全吃掉 C/C++，就被 Zig、Carbon、Mojo、安全 C++、Go 等从不同方向分流。不是一门语言统一天下，而是多语言重新划分生态位。

C/C++ 被分流是必然

C/C++ 的一部分市场，本来就是历史偶然和路径依赖。很多项目过去用 C++，不是因为 C++ 最适合，而是因为：当时没有 Rust；Go 还没成熟；Java/C# 有 GC；Python 太慢；需要性能；需要系统接口；团队习惯；行业默认。但很多项目其实不需要 C++ 那种极端自由，比如：普通业务系统；普通网络服务；大量工具；安全扫描器；数据处理管道；日志系统；包管理器；新的 CLI；新的代理服务；普通后端；部分中间件；部分系统组件。这些项目需要的是：足够性能；可维护性；安全性；好部署；好招聘；好工具链；少踩坑。它们并不需要：全局裸指针自由；到处 reinterpret_cast；手动释放；Undefined Behavior；复杂模板怪物；任意内存别名；任意对象生命周期 hack。过去很多项目是 “用大炮打蚊子”：只是想要性能，却被迫承受 C++ 的复杂性和内存风险。所以这些领域被 Rust、Go、Java、C#、Swift、Python、TypeScript 分流是必然的。C++ 会失去很多本来不该属于它的新增项目。这不是坏事。反而说明语言生态变成熟了。

C 和 C++ 仍有很难被分流的东西

虽然 C/C++ 会被分流，但不能说它们只靠历史活着。即使不谈存量生态，它们也有语言模型层面的硬优势。而且 C 和 C++ 的硬优势不一样。

C ：极薄底层边界能力

C 最强的地方，不是它安全，不是它现代，而是它足够薄。C 接近一种 “可移植汇编”。它适合表达：函数；指针；数值；struct；内存布局；调用约定；系统边界；硬件寄存器；ABI。C 的最硬优势之一是 C ABI。几乎所有语言都能调用 C：Rust 调 C；Python 调 C；Java 通过 JNI 调 C；C# P/Invoke 调 C；Go 调 C；Swift 调 C；Zig 调 C；Lua/Ruby/Node 原生扩展也大量围绕 C ABI。C ABI 是事实上的跨语言最低公分母。相比之下：C++ ABI 复杂；Rust ABI 不稳定；Go/Java/C# 有运行时模型；Swift ABI 有平台语境；Python 不是系统 ABI。所以未来即使一个库内部用 Rust 写，对外接口很可能仍然是 C ABI，比如：

1
2

int library_do_something(const char* input, size_t len);

C 可能不再是实现语言首选，但会长期是接口语言、边界语言、胶水语言。

C 适合最小运行时和裸机

有些地方你什么都没有：没有堆；没有线程；没有文件系统；没有动态链接器；没有异常；没有标准库；没有完整 runtime；甚至还在启动阶段，比如：bootloader；内核早期初始化；裸机固件；芯片 bring-up；runtime stub；freestanding 环境；极小 MCU 程序；硬件测试程序。C 在这里非常自然。Rust 也有 no_std，Zig 也能做，但 C 的语言模型天生就很薄。你基本知道一段 C 会生成什么样的机器码，需要什么运行时支持。这在极底层仍然很有价值。

C 适合硬件寄存器

硬件手册里经常直接给 C 宏或 C 结构体，比如：

1
2
3
4

#define UART_BASE 0x40001000
#define UART_DR   (*(volatile uint32_t *)(UART_BASE + 0x00))
#define UART_SR   (*(volatile uint32_t *)(UART_BASE + 0x04))

这种东西用 C 写就是自然。C 当然有坑：padding；alignment；endianness；bit field 可移植性；strict aliasing；volatile 语义复杂。但它和硬件文档、寄存器、协议头、DMA buffer、boot protocol 的心智距离很近。因此 C 很难从这些底层边界彻底退出。

C++：复杂高性能工程表达力

C++ 的硬优势和 C 不一样。C 是薄、简单、贴近 ABI。C++ 是复杂、强大、能承载大型高性能抽象系统。它的核心能力是：

零成本抽象 + 极端自由 + 能容纳现实工程的混乱。

零成本抽象仍然非常强

C++ 可以写很高级的抽象，同时努力不为没用到的东西付运行时成本。它有：templates；constexpr；concepts；RAII；move semantics；inline；operator overloading；expression templates；CRTP；policy-based design；allocator-aware containers；ranges；metaprogramming。这些东西复杂，但高手可以用它们构建非常强的高性能库。比如 Eigen 这种线性代数库，就大量依赖 expression templates，把数学表达式压到编译期优化。游戏引擎、图形库、数值库、HPC 库、数据库执行引擎，也经常需要这种 “高层抽象 + 低层性能” 的混合能力。Rust 也有零成本抽象，而且内存安全更强。但 C++ 在某些领域的表达自由度和历史积累非常深。尤其是当你需要把高级抽象、手写内存管理、平台特化和老接口全部揉在一起时，C++ 仍然很顺手。

C++ 的 RAII 表达非常成熟

C++ 的 RAII 是极其强大的思想。资源不只是内存，还包括：文件句柄；socket；mutex；GPU resource；texture；command buffer；transaction；lock guard；mmap；database handle；temporary arena；scope rollback。C++ 用构造函数和析构函数表达资源生命周期，非常自然。Rust 的 ownership 和 Drop 在这方面也很强，甚至更安全。但 C++ 的 RAII 与对象模型结合得非常深，很多工程师已经形成了很成熟的资源管理习惯。在一些复杂系统中，C++ 的灵活性仍然非常高。

C++ 特别适合共享可变状态

很多现代安全语言都希望你说清楚：谁拥有对象；谁借用对象；谁能修改对象；生命周期多长；是否跨线程；是否共享；是否可变。这是好事。但很多真实系统就是非常不规则：游戏场景图；GUI object tree；编译器 IR；数据库执行计划；ECS；observer list；callback registry；plugin system；cache；双向引用；parent-child 互指；图结构；异步任务图。C++ 对这些东西非常宽容。你可以混用：裸指针；unique_ptr；shared_ptr；weak_ptr；引用；handle；ID；arena；intrusive container；object pool。Rust 也能做，但往往需要：Rc<RefCell<T>>；Arc<Mutex<T>>；arena；generational index；slotmap；unsafe；重新设计所有权结构；更数据导向的架构。Rust 最终可能让结构更清晰，但前期架构约束更强。而 C++ 允许你直接表达很多 “不干净但现实” 的结构，比如一些很经典但复杂的数据格式。

“歪门邪道” 的价值

有些项目特别能说明 C/C++ 的生命力。ffmpeg 就是典型。ffmpeg 不是一个普通的视频库。它是几十年：

奇怪格式；历史兼容；坏文件；手写 SIMD；汇编优化；硬件编解码；跨平台；性能压榨；容错；黑魔法；工程妥协。堆出来的系统怪物。这种东西不是 Rust 写不出来，而是：它的价值不只是代码本身，而是几十年现实世界的脏活和经验。Rust 的语言安全当然有吸引力，但要替代 ffmpeg 这种工程怪物，不是语法更现代就够了。类似的还有一些科学计算库、数值库、HPC 库。它们可能有：Fortran 历史接口；C ABI；BLAS/LAPACK 生态；手写汇编；AVX/AVX2/AVX-512；GPU kernel；CUDA；编译器特定优化；数值稳定性经验；奇怪矩阵布局；cache blocking；SIMD trick；平台特化；“歪门邪道但有效” 的数学和工程技巧。这些项目往往不是 “干净的系统工程”，而是 “极端性能工程 + 历史兼容 + 数学技巧 + 硬件细节” 的混合物。C/C++ 很适合这种混沌。

歪门邪道的人也是生态位

Heng Li 那句调侃 ^[1] 很有意思：

Am I switching to Rust? Not in the near future. I enjoy the freedom of shooting myself in the foot.

翻译过来就是：我会转 Rust 吗？短期不会。我享受开枪打自己脚的自由。这句话乍看像是在开玩笑，但它抓住了 C/C++ 的一种文化心理。有些程序员确实喜欢，或者确实需要：控制每一个字节；看汇编；手写 allocator；手动 SIMD；对齐优化；利用平台细节；写 JIT；做二进制 patch；维护 ABI；绕过抽象层；和编译器斗智斗勇；为 2% 性能提升重写内存布局；在危险边缘跳舞。他们不是不知道危险。他们的态度是：我知道危险，但我需要这种自由。我愿意承担代价。Rust 对这类人有时会显得管得太多。Rust 的哲学是：危险可以做，但你要进入 unsafe，并且把边界圈起来。C++ 的哲学更像：世界是开放的，你自己负责。对大型组织来说，Rust 的哲学更健康。但对某些顶级底层工程师、性能工程师、科学计算库作者、视频编解码专家、游戏引擎黑魔法师来说，C++ 的自由仍然非常有吸引力。而纵观那些改变人类或者创造历史的项目，不少就出自这样一群人之手。

C++ 的真正哲学

C++ 之父 Bjarne Stroustrup 有一段话很值得反复看：

Someone who claims to have a perfect programming language is either a salesman or a fool, or both. ^[2]

声称自己有完美编程语言的人，要么是销售，要么是傻瓜，或者两者都是。他还说过：

My aim was for C++ to become the second best language for many things.

他的目标不是让 C++ 成为所有事情的最佳语言，而是成为很多事情的第二好语言。这句话一开始会让很多人震惊：

为什么不追求第一？

但这是非常现实的语言哲学。因为：

There can’t be a language that’s best for everything and everybody.

不可能有一门语言对所有事、所有人都是最佳。每个领域理论上都可以有最理想的 DSL：SQL 适合关系查询；shader language 适合 GPU shader；Verilog/VHDL 适合硬件描述；regex 适合文本模式；Python 适合胶水和 AI 上层；Lua 适合嵌入脚本；MATLAB/R 适合统计和数值原型；Rust 适合安全系统组件；C 适合 ABI 和裸机；C++ 适合复杂高性能框架。但这些理想语言之间有一个问题：它们怎么互操作？如果每个领域都用自己的小语言，系统怎么构建？怎么调试？怎么部署？怎么共享内存？怎么组合成一个大型产品？Bjarne 的回答是：需要一个通用框架，C++ 就试图成为这样的框架。C++ 的强项不是每个点都最优雅，而是它可以承载各种风格：C 风格；面向对象；泛型；函数式；模板元编程；编译期计算；宏；RAII；异常；无异常；RTTI；无 RTTI；裸指针；智能指针；手写内存池；嵌入式 DSL；平台 hack。C++ 里面可以长出：Eigen；Qt；Unreal；LLVM；Boost；ranges；coroutine framework；allocator framework；expression templates；游戏对象系统；GUI 框架；编译期 DSL；GPU 抽象层。这些东西不一定美，但它们能装下现实世界的复杂性。所以 C++ 的哲学可以概括为：我不保证你不受伤，但我给你最大表达空间。Rust 的哲学则是：我尽量不让你受伤，但你要按照我的规则表达问题。这不是简单的先进和落后。这是两种工程哲学。

未来格局

未来较可能的格局既不是 Rust 消灭 C++，也不是 C++ 完全不受影响，而是 C/C++ 在新增项目中被系统性分流：Rust 在新系统工程中扩大采用，C++ 保留复杂高性能场景，C 则继续承担底层边界和 ABI 的角色。

Rust 的主战场

Rust 较容易进入那些需要接近 C/C++ 的性能和控制力，又不希望继续承担其内存安全风险的新系统项目。例如新网络基础设施、代理和网关、存储与数据库组件、安全边界组件、各类解析器、虚拟化和容器基础设施、WebAssembly runtime、CLI、构建工具、包管理器和开发工具链，以及部分 OS 组件、中高端嵌入式、云基础设施和高性能服务。在这些场景中，Rust 会逐渐成为常被优先评估的选项。

C++ 的保留地

C++ 仍会广泛用于游戏引擎、图形渲染、音视频编解码、ffmpeg 一类长期演化的项目、复杂高性能库、HPC、科学计算底层、ML runtime、物理仿真、CAD/CAE/EDA、高频交易、浏览器部分模块、工业软件和大型桌面软件。对于需要大量底层处理、平台特化和历史兼容的系统，它的表达自由度和抽象能力仍有实际价值。

C 的保留地

C 会长期存在于 C ABI、libc、syscall 接口、bootloader、裸机、芯片 SDK、内核极底层、语言 runtime、动态库接口、嵌入式小固件、硬件寄存器定义、平台胶水和 freestanding 环境中。它在许多项目中的角色，可能会从主要实现语言逐步更多转向底层公共边界语言。

其他语言的领地

许多领域本就不必由 Rust 或 C++ 主导。企业业务常使用 Java、C# 或 Kotlin，云服务常使用 Go、Java 或 C#；AI 上层与数据分析多依赖 Python、R 和 SQL，前端使用 TypeScript，移动端使用 Swift、Kotlin 或 Dart，脚本自动化使用 Python 和 Shell。Mojo、Triton、CUDA 等也可能在 AI/HPC 中形成新的路径。Rust、C++ 和其他现有或未来的语言，都不可能是所有问题的最佳答案，这也印证了 “没有一门语言适合所有事情和所有人”。

作为 C++ 开发者真正应该学什么？

这个讨论最终会落到职业发展上。对 C++ 开发者而言，若能力只停留在语言语法、STL、少量模板和业务逻辑，而缺少系统、性能、内存模型、ABI、工具链、安全、并发和其他语言生态的认识，选择空间可能会变窄。这并不只与 Rust 有关；多年来，Java、Go、C#、Rust、Python 和 TypeScript 已在不同场景中承接了原本可能由 C++ 完成的项目。学习 Rust 是一种补充方式，而 C++ 开发者更有价值的能力通常位于复杂系统和性能工程的深处。

学 Rust，补内存安全思维

即使主要使用 C++，学习 Rust 也有帮助，并不意味着必须转向 Rust。它会促使开发者重新理解所有权、借用、生命周期、移动语义、别名、共享可变性、数据竞争，以及 API 如何表达所有权和缩小 unsafe 的边界。再回头写 C++ 时，便会更自然地审视对象由谁拥有、谁只是观察者、谁可以修改、生命周期何时结束、引用是否可能悬垂，以及 unique_ptr、shared_ptr、span、string_view 或 move-only 对象是否更合适。Rust 对 C++ 开发者的意义，不只是多掌握一门语言，也是建立更严格的所有权和生命周期意识。

深挖 C++ 的王牌区能力

C++ 开发者可以强化性能工程、系统编程、内存模型、并发、ABI、编译链接、工具链、crash debugging、sanitizers、fuzzing、profiling、SIMD、allocator、cache locality、lock-free、NUMA、CPU pipeline 和 branch prediction 等能力。关键不在于掌握多少语法，而在于能解释并处理具体问题：代码为何变慢，cache miss 或 false sharing 从何而来，哪里可能触发 UB，线上 core dump、链接失败和 ABI 不兼容如何发生，allocator 为何造成性能抖动，锁为何成为瓶颈，数据结构为何不适合 CPU cache。这些能力决定了复杂工程中的处理范围。

选一个行业纵深

C++ 最好与一个具体的技术领域结合。例如，音视频会涉及 ffmpeg、codec、container format 与 SIMD；游戏需要面对引擎、ECS、渲染、资源和脚本系统；数据库、网络、编译器、图形、ML runtime、嵌入式、低延迟系统和科学计算也各有其底层问题。C++ 的能力往往在深入这些复杂系统之后才会显现出来。

形成 T 型能力

横向上，需要理解不同语言适合解决什么问题：Rust 面向安全系统工程，C 面向 ABI 和极底层，Go 常见于云原生和平台服务，Python 用于 AI、脚本与胶水，TypeScript 用于前端和工具链，Java/C# 用于企业与业务系统，Zig 和 Mojo 则提供了值得关注的新方向。纵向上，则需要积累 C++ 复杂工程的能力。成熟的 C++ 开发者并不是到处推行 C++，而是能判断何时使用它、何时选择别的工具。

未来不是取代，而是重新分工

这场讨论不必归结为 “Rust 会不会取代 C++”。Rust 会在新系统工程中扩大采用，尤其会影响安全敏感的新项目；C++ 仍会服务于复杂高性能、底层处理、历史兼容和长期演化的大型工程；C 继续留在 ABI、裸机、系统边界和平台胶水等位置。业务、AI、前端、移动和脚本，也会由更贴合场景的语言承担。

语言并不沿着一条直线更替，而是在新的需求里调整位置。Rust 改变的是新项目的起点，C++ 保留的是复杂工程的纵深，C 守住的是系统边界。对开发者而言，理解这些边界，比站在某一门语言一边更重要；工具各有来处，也各有去处。

这不是语言战争的结束。

这只是软件工业开始更成熟地分配工具。

这何尝不是一件好事？

静态托管的优化关键在于分配到更好的 IP。对于 Vercel、Netlify、Cloudflare 等厂商，分配到的 IP 往往不尽人意。分配到更好的 IP，就可以极大缓解不稳定的情况，并且大幅度提速。

Vercel / Netlify

先使用官方 CNAME 获取到 SSL 证书，然后换成：

1
2

vercel.example.com.1INCNAMEvercel-cname.xingpingcn.top. ; cf_tags=cf-proxied:false
netlify.example.com.1INCNAMEnetlify.cname.bee-zh.cn. ; cf_tags=cf-proxied:false

由于 CNAME 的 IP 的质量并不能总是保持优质，需要隔三差五检查。

另有：

1
2
3

vercel.example.com.1INCNAMEvercel.cname.bee-zh.cn. ; cf_tags=cf-proxied:false
netlify.example.com.1INCNAMEnetlify-cname.xingpingcn.top. ; cf_tags=cf-proxied:false
netlify.example.com.1INCNAMEsth.netlify.com. ; cf_tags=cf-proxied:false

Cloudflare Pages

使用任意支持地域化解析的 DNS 供应商（可惜 Cloudflare 免费版不支持，可以 NS 到支持的，比如阿里），国外解析到 sth.pages.dev，国内解析到 cf.877774.xyz

Cloudflare CDN

使用 Cloudflare SaaS（Software as a Service, 软件即服务）中的自定义主机名功能，具体可参考这个视频，皮皮虾老师讲的非常清楚，鄙人不多赘述。

单点服务器

自托管服务器的网站问题则更大了。

HSTS Preload

由于 HTTP 不加密，首次访问可能会被劫持，没有机会建立 HTTPS 连接；若无 HSTS（HTTP Strict Transport Security，HTTP 严格传输安全），攻击者甚至还可以阻断 HTTPS 的连接。即使加上 HSTS 头，从一般用户角度来说，也往往需要首次的 HTTP。

那怎么办？加入 HSTS Preload（HSTS Preload List，HSTS 预加载列表） 列表（这个列表随着每次浏览器的发布而更新）后，你的网站会自动启用 HSTS，首次访问即为 HTTPS。代价就是 SSL 证书爆炸的话无路可退，只能等下一次浏览器发布的时候退出列表。

进入 preload 列表必须 max-age ≥ 31536000 且 includeSubDomains 且 preload。为了避免这个问题，建议从较小的 max-age 起递增。

加上这个头：

1

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Copy from Google：

max-age 指令用于指定用户浏览器必须仅使用 TLS 访问网站的时间量（以秒为单位）。一旦时间过去，如果网站未提供 HSTS 标头（或从 HTTP 到 HTTPS 的临时重定向），用户就可以再次通过纯 HTTP 访问该网站。

设置 includeSubDomains 指令会强制在最初发送标头的网页网址的任何子网域上使用该标头。例如，如果 google.com 发送的 HSTS 标头包含 includeSubDomains 指令，则会在 mail.google.com 上强制执行 HSTS 标头。

设置 preload 指令并将网域提交给 HSTS 预加载服务后，系统会将该网域编译到使用预加载 HSTS 列表的浏览器二进制文件中。不仅 Google Chrome 如此，其他主流浏览器也会使用该列表。

泛解析

某一个域名的所有子域名指向同一个网站，一定程度上起到镜像站的作用。有些时候 ISP（Internet Service Provider，互联网服务提供商，也就是运营商） 不会下狠手，只会封禁一个子域名。

DNSSEC

DNS 污染是对于小网站成本较低、伤害较大的一个招式。当受到大范围的 DNS 投毒时，上游的权威 DNS 都会受到污染，DoT 和 DoH 也无力回天。

DNSSEC（Domain Name System Security Extensions，域名系统安全扩展） 通过引入数字签名来确保 DNS 响应的真实性和完整性。哪怕攻击者劫持了 DNS，也难以伪造签名，这个错误的 DNS 解析结果会被拒绝。它确保了你的浏览器在发起 HTTP/HTTPS 请求时，连接的是正确、合法的服务器。

Cloudflare 提供免费的 DNSSEC，可以按照博客开启。

CAA

CAA（Certificate Authority Authorization，证书颁发机构授权）是规定哪些 CA（Certificate Authority，证书颁发机构）有权为域名签发证书的白名单。

1
2
3

example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issue "pki.goog"
example.com. CAA 0 issue "digicert.com"

这可以有效防止黑 CA 或者 ISP 通过颁发假证书的方法进行攻击。如果 CA 胆敢违反 CAA 颁发证书，那么可能会被吊销执照。

CT

但是，某些 ISP 掌握或者胁迫正规 CA 颁发证书，这个时候 CT（Certificate Transparency，证书透明度）就会出手。CT 会记录下每一张证书，方便进行审核。什么？你想不提交到 CT 来逃过审核？那这张证书会因为没有有效的 SCT（Signed Certificate Timestamp，证书签署时间戳）而被浏览器拒绝。

OCSP / CRL

证书已经出问题了，怎么办？

• CRL（Certificate Revocation List，证书吊销列表）：CA 定期发布一个包含所有已吊销证书序列号的大列表，浏览器需要下载并检查。
• OCSP（Online Certificate Status Protocol，在线证书状态协议）：浏览器向 CA 的 OCSP 服务器实时查询证书状况。
• OCSP Stapling（OCSP Stapling，OCSP 装订）：网站服务器自己定期去查询 OCSP 状态，并将有效的 OCSP 响应与证书一起 “装订” 起来发给浏览器。这避免了浏览器自己去查询，减少了延迟和被 ISP 拦截的风险。但如果 ISP 是中间人，它也可以替换掉这个 “装订” 的响应。

似乎装订 + 短期证书（90d）更有效，靠撤销长期证书有点亡羊补牢？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# https://ssl-config.mozilla.org/#server=nginx&version=1.27.3&config=modern&openssl=3.4.0&hsts=false&guideline=5.7

# OCSP stapling
ssl_stapling on;
ssl_stapling_verify on;

# verify chain of trust of OCSP response using Root CA and Intermediate certs
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

# replace with the IP address of your resolver;
# 这里我替换成了 1.1.1.1
# async 'resolver' is important for proper operation of OCSP stapling
resolver 1.1.1.1;

# If certificates are marked OCSP Must-Staple, consider managing the
# OCSP stapling cache with an external script, e.g. certbot-ocsp-fetcher

通用

ECH

ECH（Encrypted ClientHello，加密客户端问候） 理论上可以保护隐私、对抗封禁。

客户端

Firefox 119 已经默认启用 ECH，Chrome/Edge 据说是 105 开始默认启用，总之最新的浏览器没问题的。启用浏览器内置的安全 DNS（Cloudflare、Google 等主流均可），然后尝试访问 https://tls-ech.dev/，看到 You are using ECH. :) 就可以了。

服务器

Cloudflare CDN 免费版默认启用 ECH，Pages 似乎没有。

包括 OpenSSL、Curl、Nginx 等项目对于 ECH 的支持大多停留在实验阶段，故单点服务器难以上手。

你可以使用 Google Public DNS 查询网站的支持情况，HTTPS 记录中包含 ech= 即可。

Firefox 用户还可以安装 oh-my-ech 插件实时查看网站的 ECH 情况。

CSP 与 SRI

自己的网站百密无疏了，但是别忘了上游 CDN 投毒也是网络安全的重要话题。StaticFile、BootCDN、51LA 等都发生过投毒事件。

可以通过 CSP（Content Security Policy，内容安全策略）头限制资源加载：

1
2

<meta http-equiv="Content-Security-Policy"
      content="default-src 'self'; script-src 'self' trusted.com">

通过 SRI（Subresource Integrity，子资源完整性）防止资源被篡改：

1
2
3

<script src="https://cdn.example.com/jquery.js"
        integrity="sha384-..."
        crossorigin="anonymous"></script>

鸣谢与引用

1. [矛与盾] 运营商封锁的原理以及 “低成本” 解决方案
2. Cloudflare：
   1. https://www.cloudflare.com/zh-cn/learning/dns/dnssec/universal-dnssec/
   2. https://blog.cloudflare.com/zh-cn/announcing-encrypted-client-hello/
3. Mozilla
   1. https://developer.mozilla.org/zh-CN/docs/Web/Security/Certificate_Transparency
   2. https://ssl-config.mozilla.org/

本文极为简略，仅作为学习笔记使用，许多证明步骤未写出．

均值不等式

$\frac{a+b}{2} \geq \sqrt{ab}$

这是高中数学课本上第一个重要的不等式，A 版教材称为基本不等式，B 版教材称为均值不等式．

其中，$\frac{a+b}{2}$ 称为算术平均值，$\sqrt{ab}$ 称为几何平均值．

证明

画图中……

变形

均值不等式有多个变形 / 推广形式，极其常用的有：

$a+b \geq 2\sqrt{ab} \nobreakspace(a,b \in R_+)$

$ab \leq (\frac{a+b}{2})^2 \nobreakspace(a,b \in R_+)$

此外还有：

$a+\frac{1}{a} \geq 2 \nobreakspace(a>0)$

$\frac{a}{b}+\frac{b}{a} \geq 2 \nobreakspace(\frac{a}{b}>0)$

$a^2+b^2 \geq 2ab \nobreakspace(a,b \in R)$

应用

均值不等式的应用有三个条件：

1. 一正： 两个数均为正实数，即 $a,b \in R_+$．
2. 二定： 求和时积为定值，求积时和为定值．
3. 三相等： 等号能成立，即等号成立的条件能满足．

特殊情况

一不正

条件一正没有满足即为一不正，又分为两种情况：

一不正

$a,b$ 一正一负，即 $a > 0, b < 0$．

一不正时，均值不等式不成立，无法利用均值不等式求解．此时应放弃均值不等式，尝试将原式化为 $f(x) = x-\frac{p}{x} \nobreakspace(p > 0)$ 的形式．此函数为飘带函数，随后便可以利用函数的单调性求解．

二不正

$a,b$ 均为负实数，即 $a,b < 0$．

类似的，此时均值不等式不成立，无法利用均值不等式求解．此时应放弃均值不等式，提取 $a,b$ 的负号，利用均值不等式求解之后，再利用不等式的基本性质二恢复负号．

二不定

条件二定没有满足即为二不定．此时均值不等式不成立，无法利用均值不等式求解主要利用配凑的方法求解．又分为两种情况：

求和积不定

利用加减等方法凑出分母的倍数．

例：当 $x > 1$ 时，求 $x+\frac{4}{x-1}$ 的最小值．

将 $x+\frac{4}{x-1}$ 转化为 $(x-1)+\frac{4}{x-1}+1$．检验 $x-1 > 0$ 且 $\frac{4}{x-1} > 0$ ，则有：

$$\begin{aligned} (x-1)+\frac{4}{x-1}+1 &\geq 2\sqrt{(x-1)\cdot\frac{4}{x-1}}+1 \\ &= 2\sqrt{4}+1 \\ &= 5\end{aligned}$$

当且仅当 $x-1 = \frac{4}{x-1}$，即 $x = 3$ 时，等号可以成立，得出 $x+\frac{4}{x-1}$ 的最小值为 $5$．

求积和不定

改变某一因式系数使和为定值．

例：当 $x \in (0,1)$ 时，求 $x(3-2x)$ 的最大值．

将 $x(3-2x)$ 转化为 $\frac{1}{2}\cdot2x(3-2x)$．检验 $2x > 0$ 且 $3-2x > 0$ ，则有：

$$\begin{aligned} \frac{1}{2}\cdot2x(3-2x) &\leq \frac{1}{2}\cdot\left[\frac{2x+(3-2x)}{2}\right]^2 \\ &= \frac{1}{2}\cdot\frac{9}{4} \\ &= \frac{9}{8}\end{aligned}$$

当且仅当 $2x = 3-2x$，即 $x = \frac{3}{4}$ 时，等号可以成立，得出 $x(3-2x)$ 的最大值为 $\frac{9}{8}$．

三不相等

此时均值不等式不成立，无法利用均值不等式求解．此时应放弃均值不等式，尝试将原式化为 $f(x) = x+\frac{p}{x} \nobreakspace(p > 0)$ 的形式．此函数为对勾函数，其两个拐点一正一负，横坐标为 $\sqrt{p}$ 和 $-\sqrt{p}$，代入求值得出拐点坐标后便可以利用函数的单调性求解．

1 的代换

1 的代换法是将代数式同时乘以 “1”，转化为均值不等式求解，通常是给出一个和，再求一个和的形式．

例：正数 $x,y$ 满足 $\frac{3}{x}+\frac{1}{y} = 5$，求 $3x+4y$ 的最小值．

$$\begin{aligned} 3x+4y &= 1\cdot(3x+4y) \\ &= \frac{1}{5}\cdot(\frac{3}{x}+\frac{1}{y})\cdot(3x+4y) \\ &= \frac{1}{5}\cdot(\frac{3}{x}\cdot3x+\frac{3}{x}\cdot4y+\frac{1}{y}\cdot3x+\frac{1}{y}\cdot4y) \\ &= \frac{1}{5}(9+\frac{12y}{x}+\frac{3x}{y}+4) \\ &\geq \frac{1}{5}\cdot(9+4+2\sqrt{\frac{12y}{x}\cdot\frac{3x}{y}}) \\ &= \frac{1}{5}(9+4+12) \\ &= 5\end{aligned}$$

当且仅当 $\frac{12y}{x} = \frac{3x}{y}$ 时，等号成立．联立方程：

$$\begin{cases} \frac{3}{x} + \frac{1}{y} = 5 \\ \frac{12y}{x} = \frac{3x}{y}\end{cases}$$

解得：

$$\begin{cases} x = 1 \\ y = \frac{1}{2}\end{cases}$$

满足条件，可得 $3x+4y$ 的最小值为 $5$．

重要不等式

证明

由完全平方公式：$(a-b)^2 = a^2-2ab+b^2$

由平方的非负性：$x^2 \geq 0$

可以得到：$a^2-2ab+b^2 \geq 0$

移项即可得：$a^2+b^2 \geq 2ab$

可作为均值不等式的补充．

由于平方的性质中 $x \in R$，因此重要不等式的条件略有不同：

1. 一实： 两个数均为实数，即 $a,b \in R$．
2. 二定： 求和时积为定值，求积时和为定值．
3. 三相等： 等号能成立，即等号成立的条件能满足．

连续不等式

均值不等式的全部如下：

$\frac{n}{\frac{1}{a_1} + \frac{1}{a_2} + \cdots + \frac{1}{a_n}} \leq \sqrt[n]{a_1 \cdot a_2 \cdots a_n} \leq \frac{a_1 + a_2 + \cdots + a_n}{n} \leq \sqrt{\frac{a_1^2 + a_2^2 + \cdots + a_n^2}{n}}$，其中：

$\frac{n}{\frac{1}{a_1} + \frac{1}{a_2} + \cdots + \frac{1}{a_n}}$ 是调和平均值，

$\sqrt[n]{a_1 \cdot a_2 \cdots a_n}$ 是几何平均值，

$\frac{a_1 + a_2 + \cdots + a_n}{n}$ 是算术平均值，

$\sqrt{\frac{a_1^2 + a_2^2 + \cdots + a_n^2}{n}}$ 是平方平均值．

这个不等式链展示了不同平均值之间的大小关系．

糖水不等式

一杯质量为 $b$ 的糖水含有质量为 $a$ 的糖分，易得该杯糖的质量浓度为 $\frac{a}{b}$．向杯中加入质量为 $c$ 的糖，易得该杯糖水的质量浓度为 $\frac{a+c}{b+c}$．由常识即可得 $\frac{a}{b} < \frac{a+c}{b+c}$．并由情境得：$b>a>0,c>0$．

证明

作差：$\frac{a}{b} - \frac{a+c}{b+c}$

简化后得到：$\frac{c(a - b)}{b(b+c)} > 0$

所以不等式 $\frac{a}{b} < \frac{a+c}{b+c}$ 在 $a>b>0,c>0$ 时成立．

权方和不等式

$\frac{x^2}{a}+\frac{y^2}{b} \geq \frac{(x+y)^2}{a+b} \nobreakspace(a,b,x,y \in R_+)$

证明

$$\begin{aligned} (\frac{x^2}{a}+\frac{y^2}{b})\cdot(a+b) &= x^2+\frac{bx^2}{a}+\frac{ay^2}{b}+y^2 \\ &\geq x^2+y^2+2\sqrt{\frac{bx^2}{a}\cdot\frac{ay^2}{b}} \\ &= x^2+y^2+2xy \\ &=(x+y)^2\end{aligned}$$

利用不等式的基本性质二即可得到 $\frac{x^2}{a}+\frac{y^2}{b} \geq \frac{(x+y)^2}{a+b}$

1. 部分软件未针对 Arch Linux 进行适配，导致出现兼容性问题。
2. 部分软件的默认配置不尽合理，或与每个人的情况不符，需要进行调整。
3. 系统的部分行为不够合理，需要进行调整。

Alsa 的配置与兼容

Alsa 是 Linux 声卡驱动程序，通常是 Linux 默认的声卡驱动程序。

ArchLinux 的 Alsa 包 似乎没有附带默认配置文件，因此难免遇到问题，此处以我自己用到的 ClassIn 为例。

除去软件自带的错误的库

由于 ClassIn 自带一部分 Alsa 库，导致 Alsa 无法正常工作，ClassIn 成了聋哑软件。

1
2
3
4
5
6

ALSA lib dlmisc.c:170:(snd_dlsym_verify) unable to verify version for symbol snd_func_private_integer
ALSA lib conf.c:4556:(_snd_config_evaluate) symbol snd_func_private_integer is not defined inside (null)
ALSA lib conf.c:5047:(snd_config_expand) Evaluate error: 没有那个设备或地址
ALSA lib conf.c:3694:(snd_config_hook_load) Unable to expand filenames in the pre-load section
ALSA lib conf.c:3572:(snd_config_hooks_call) function snd_config_hook_load_for_all_cards returned error: 没有那个设备或地址
ALSA lib control.c:1264:(snd_ctl_open_conf) Invalid type for CTL default definition

直接删除即可：

1

rm -rf /opt/apps/classin/lib/libasound.so*

调整配置文件

指定设备

再次运行 ClassIn，仍然报错，并且找不到扬声器 / 耳机，只找到麦克风：

1
2
3
4
5
6
7
8

ALSA lib pcm_dmix.c:1000:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm_dmix.c:1000:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm_dmix.c:1000:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm_dmix.c:1000:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm_dmix.c:1000:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm_dmix.c:1000:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm_dmix.c:1000:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm_dmix.c:1000:(snd_pcm_dmix_open) unable to open slave

看起来是没找到设备，指定下就好了。

先找一下设备：

1

aplay -l

输出类似如下内容：

1
2
3
4
5
6
7
8
9
10

**** List of PLAYBACK Hardware Devices ****
card 1: PCH [HDA Intel PCH], device 0: ALC897 Analog [ALC897 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: PCH [HDA Intel PCH], device 1: ALC897 Digital [ALC897 Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: HDMI [HDA ATI HDMI], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

发现有两个 Card，分别是 PCH 和 HDMI，其中 PCH 卡有两个 Device，分别是 ALC897 Analog 和 ALC897 Digital，HDMI 卡有一个 Device HDMI 0。

编辑 /etc/asound.conf 文件，指定声卡。这里我添加如下内容：

1
2
3
4
5
6
7
8
9
10

pcm.!default {
    type hw
    card 1
    device 0
}

ctl.!default {
    type hw
    card 1
}

当然，也可以用设备名称来指定。

核实下设备名：

1

aplay -l | awk -F \: '/,/{print $2}' | awk '{print $1}' | uniq

输出如下内容：

1
2

PCH
HDMI

改写配置文件：

1
2
3
4
5
6
7
8
9
10

pcm.!default {
    type hw
    card PCH
    device 0
}

ctl.!default {
    type hw
    card PCH
}

这样就指定了默认的声卡为 PCH。

调节声道

再次运行 ClassIn，仍然报错，而且更糟糕的是输入输出都没有声音——又成聋哑软件了：

1
2
3
4
5
6
7

ALSA lib pcm.c:8832:(snd_pcm_set_params) Channels count (1) not available for PLAYBACK: 无效的参数
ALSA lib pcm.c:8832:(snd_pcm_set_params) Channels count (1) not available for CAPTURE: 无效的参数
ALSA lib pcm.c:8832:(snd_pcm_set_params) Channels count (1) not available for PLAYBACK: 无效的参数
ALSA lib pcm.c:8832:(snd_pcm_set_params) Channels count (1) not available for PLAYBACK: 无效的参数
ALSA lib pcm.c:8832:(snd_pcm_set_params) Channels count (1) not available for PLAYBACK: 无效的参数
ALSA lib pcm.c:8832:(snd_pcm_set_params) Channels count (1) not available for PLAYBACK: 无效的参数
ALSA lib pcm.c:8832:(snd_pcm_set_params) Channels count (1) not available for PLAYBACK: 无效的参数

声道不太对，调整下配置文件：

1
2
3
4
5
6
7
8
9

pcm.!default {
    type plug
    slave.pcm "hw:1,0"
}

ctl.!default {
    type hw
    card 1
}

这将使用 plug 插件自动转换音频参数以匹配设备的支持范围。

再次运行 ClassIn，声音设备正常了。

后记

还有许多可以修改的，比如解决 Alsa 与 PulseAudio 的冲突，日后再补充……

FontConfig 的美化

FontConfig 是 Linux 字体管理器，负责管理系统中字体文件的搜索路径、渲染方式、字体匹配规则等。

FontConfig 默认配置对 CJK + 编程的应用场景来说并不友好，会遇到以下问题：

1. CJK 字形错乱，简体中文、繁体中文、日文、韩文等字形混用
2. 字体渲染效果不佳，缺少粗体、斜体等效果
3. 终端设置等宽字体会导致 CJK 字符回退到宋体，设置 CJK 字体会导致等宽字体的错乱
4. 缺失 Windows 下常用的字体（微软雅黑、黑体、宋体、Arial、Times New Roman、Courier New 等）导致显示效果不佳
5. 默认的 Sans、Serif、Monospace 等字体不够美观，并且功能欠缺
6. ZSH 的符号字体显示效果不佳

懒人篇

安装字体

1

sudo paru -S noto-fonts noto-fonts-cjk noto-fonts-emoji noto-fonts-extra ttf-font-awesome ttf-nerd-fonts-symbols ttf-th-tshyn ttf-jetbrains-mono

调整配置文件

编辑 ~/.config/fontconfig/fonts.conf 文件，添加以下内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164

<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'urn:fontconfig:fonts.dtd'>
<fontconfig>
    <!-- 拓宽系统字体设置生效面 -->
    <match target="pattern">
        <test name="family">
            <string>system-ui</string>
        </test>
        <edit binding="strong" mode="prepend" name="family">
            <string>sans-serif</string>
        </edit>
    </match>
    <match target="pattern">
        <test name="family" qual="any">
            <string>ui-monospace</string>
        </test>
        <edit binding="same" mode="assign" name="family">
            <string>monospace</string>
        </edit>
    </match>
    <match target="pattern">
        <test name="family" qual="any">
            <string>ui-sans-serif</string>
        </test>
        <edit binding="same" mode="assign" name="family">
            <string>sans-serif</string>
        </edit>
    </match>
    <match target="pattern">
        <test name="family" qual="any">
            <string>ui-serif</string>
        </test>
        <edit binding="same" mode="assign" name="family">
            <string>serif</string>
        </edit>
    </match>
    <!-- 你可以自行添加更多字体设置 -->

    <!-- 字体替换  -->
    <match target="pattern">
        <test compare="contains" name="family">
            <string>宋体</string>
        </test>
        <edit binding="strong" name="family">
            <string>serif</string>
        </edit>
    </match>
    <match target="pattern">
        <test compare="contains" name="family">
            <string>Microsoft YaHei</string>
        </test>
        <edit binding="strong" name="family">
            <string>sans-serif</string>
        </edit>
    </match>
    <match target="pattern">
        <test compare="contains" name="family">
            <string>微软雅黑</string>
        </test>
        <edit binding="strong" name="family">
            <string>sans-serif</string>
        </edit>
    </match>
    <match target="pattern">
        <test compare="contains" name="family">
            <string>Arial</string>
        </test>
        <edit binding="strong" name="family">
            <string>sans-serif</string>
        </edit>
    </match>
    <match target="pattern">
        <test compare="contains" name="family">
            <string>Source Code Pro</string>
        </test>
        <edit binding="strong" name="family">
            <string>monospace</string>
        </edit>
    </match>
    <!-- 你可以自行补充更多字体替换 -->

    <!-- 等宽字体顺序 -->
    <match target="pattern">
        <test name="family" qual="any">
            <string>monospace</string>
        </test>
        <edit binding="strong" mode="prepend" name="family">
            <string>JetBrains Mono</string>
            <string>Noto Sans Mono CJK SC</string>
            <string>Noto Color Emoji</string>
            <string>Symbols Nerd Font</string>
            <string>Font Awesome 6 Free</string>
        </edit>
    </match>

    <!-- 无衬线字体顺序 -->
    <match target="pattern">
        <test name="family" qual="any">
            <string>sans-serif</string>
        </test>
        <edit binding="strong" mode="prepend" name="family">
            <string>Noto Sans CJK SC</string>
            <string>Noto Color Emoji</string>
            <string>Symbols Nerd Font</string>
            <string>Font Awesome 6 Free</string>
        </edit>
    </match>

    <!-- 衬线字体顺序 -->
    <match target="pattern">
        <test name="family" qual="any">
            <string>serif</string>
        </test>
        <edit binding="strong" mode="prepend" name="family">
            <string>Noto Serif CJK SC</string>
            <string>Noto Color Emoji</string>
            <string>Symbols Nerd Font</string>
            <string>Font Awesome 6 Free</string>
        </edit>
    </match>

    <!-- 渲染设置 -->
    <match target="font">
        <test name="slant">
            <const>roman</const>
        </test>
        <test compare="not_eq" name="slant" target="pattern">
            <const>roman</const>
        </test>
        <edit mode="assign" name="matrix">
            <times>
                <name>matrix</name>
                <matrix>
                    <double>1</double>
                    <double>0.2</double>
                    <double>0</double>
                    <double>1</double>
                </matrix>
            </times>
        </edit>
        <edit mode="assign" name="slant">
            <const>oblique</const>
        </edit>
        <edit mode="assign" name="embeddedbitmap">
            <bool>false</bool>
        </edit>
    </match>
    <match target="font">
        <test compare="less_eq" name="weight">
            <const>medium</const>
        </test>
        <test compare="more_eq" name="weight" target="pattern">
            <const>bold</const>
        </test>
        <edit mode="assign" name="embolden">
            <bool>true</bool>
        </edit>
        <edit mode="assign" name="weight">
            <const>bold</const>
        </edit>
    </match>

    <dir>~/.fonts</dir>
</fontconfig>

解释

字体家族

字体家族（family）是指一组字体，通常包括一个默认字体和一组备用字体。

在 FontConfig 中，字体家族的设置通过 family 选项来实现。这里以 serif（有衬线字体）字体家族为例，设置字体家族的优先级：

1
2
3
4
5
6
7
8
9
10
11

<match target="pattern">
    <test name="family" qual="any">
        <string>serif</string>
    </test>
    <edit binding="strong" mode="prepend" name="family">
        <string>Noto Serif CJK SC</string>
        <string>Noto Color Emoji</string>
        <string>Symbols Nerd Font</string>
        <string>Font Awesome 6 Free</string>
    </edit>
</match>

字体家族的优先级由上到下，越靠前的字体优先级越高。建议按照以下优先级设置字体家族：

1. 中文字体
2. 英文字体
3. 表情符号
4. Icon 字体

设置字体家族后，系统会自动按照优先级匹配字体，从而有效解决问题 3、5、6。如果锁死使用某一字形，还可以粗暴但有效地解决问题 1。此外，若字体有多字重，搭配渲染设置可以解决问题 2。

字体替换

比如上面覆盖 宋体 字体与 system-ui 字体家族的配置，以解决问题 4。

渲染策略

直接使用默认配置就好了，有问题再二分法排查。啥？你没备份？我这有一份完全的默认的配置，注释都没删，罚你自己整理！

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85

<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'urn:fontconfig:fonts.dtd'>
<fontconfig>
 <!--
 Artificial oblique for fonts without an italic or oblique version
 -->
 <match target="font">
  <!-- check to see if the font is roman -->
  <test name="slant">
   <const>roman</const>
  </test>
  <!-- check to see if the pattern requested non-roman -->
  <test compare="not_eq" name="slant" target="pattern">
   <const>roman</const>
  </test>
  <!-- multiply the matrix to slant the font -->
  <edit mode="assign" name="matrix">
   <times>
    <name>matrix</name>
    <matrix>
     <double>1</double>
     <double>0.2</double>
     <double>0</double>
     <double>1</double>
    </matrix>
   </times>
  </edit>
  <!-- pretend the font is oblique now -->
  <edit mode="assign" name="slant">
   <const>oblique</const>
  </edit>
  <!-- and disable embedded bitmaps for artificial oblique -->
  <edit mode="assign" name="embeddedbitmap">
   <bool>false</bool>
  </edit>
 </match>
 <!--
 Synthetic emboldening for fonts that do not have bold face available
 -->
 <match target="font">
  <!-- check to see if the weight in the font is less than medium which possibly need emboldening -->
  <test compare="less_eq" name="weight">
   <const>medium</const>
  </test>
  <!-- check to see if the pattern requests bold -->
  <test compare="more_eq" name="weight" target="pattern">
   <const>bold</const>
  </test>
  <!--
  set the embolden flag
  needed for applications using cairo, e.g. gucharmap, gedit, ...
-->
  <edit mode="assign" name="embolden">
   <bool>true</bool>
  </edit>
  <!--
 set weight to bold
 needed for applications using Xft directly, e.g. Firefox, ...
-->
  <edit mode="assign" name="weight">
   <const>bold</const>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="rgba">
   <const>rgb</const>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="hinting">
   <bool>true</bool>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="hintstyle">
   <const>hintslight</const>
  </edit>
 </match>
 <dir>~/.fonts</dir>
 <match target="font">
  <edit mode="assign" name="antialias">
   <bool>true</bool>
  </edit>
 </match>
</fontconfig>

后记

此外，还有一些高级的设置，比如：

• 调整字体大小、粗细
• 根据语言自动调整字体
• 为某一程序调整字体
• 为某一字体调整渲染策略
• 根据应用场景自动调整渲染策略

这些设置可以根据个人喜好进行调整。我对此没有需求，未做过研究，请参阅以下资料：

• Arch Wiki: Font Configuration
• FontConfig User Documentation
• 用 fontconfig 治理 Linux 中的字体 – 双猫 CC
• Bryan2333/Dotfiles

除非您有把握，否则不建议随意调整手机默认的性能配置！默认的，往往是最好的！

流畅度

内存方向

对于 Android 11+Magisk+LSPosed+ 小而美 + QQ+etc. 来说，sdm660+4GB 已显捉襟见肘。对于小而美、QQ、B 站、抖音等软件，其本身优化就极差，再加一堆 XpHook，性能便更差了：不仅狂杀后台，而且时常会 OOM。怎么办呢？

交换空间

为了从源头上解决内存捉襟见肘的问题，我们可以使用交换空间。这里我使用 Scene 调节。

ZRAM

ZRAM 是在内存中划出一块来并对其进行压缩，详情可见 ArchWikiCN。正因如此，ZRAM 设置不当会给 CPU 带来显著的压力，进而拉大耗电量、减少续航。

如果您只打算开 ZRAM，那么建议在 2GB 到 3GB（2048MB 到 3072MB）之间。过小作用不大，过大拉多耗电量。

Swap

ZRAM+Swap

ZRAM 建议在 1.5GB 到 2.5GB（1536MB 到 2560MB）之间，Swap 建议在 0.5GB 到 1.5GB（1024MB 到 1536MB）之间，并且当 Scene 提示交换策略时，选择优先使用 ZRAM。这样可以让新鲜的数据在较快的 ZRAM 里交换，而当 ZRAM 被榨干时则把脏数据写到 Swap 以备过后使用。

VM Parameters

将 swappiness 和 extra_free_kbytes 拉得较大。这样可以保证留有充足的 RAM 以防止 OOM。

特殊版本

微信

微信版本复杂，建议参考百分之千 / 定制版应用收藏 / 版本拐点选择，并从酷安老哥微笑渲染悲伤的帖子里下载。

比较推荐的是 CN 7.0.21、Play 8.0.15、Play 8.0.33、CN 8.0.42。

不建议 OPPO R11 使用微信了，实在太卡。

QQ

建议用 9.0.8，可以从 QQUpdates、QQ/TIM Update Log 获得。9.0.15 和 9.0.17 有多人报道冷启动、小程序、扫码变慢。

时代变了，建议用 9.0.65，可以从 QQUpdates、QQ/TIM Update Log 获得。

Others

请参考以下几个视频：

安卓软件保姆级优化，让你的手机再战三年！

让老旗舰机重回新生？请收好这份养老软件指南！

三方客户端

对于某些热门软件，可能会有大佬用爱发电。传送门有：

• PiliPlus（哔哩哔哩）
• Hydrogen（知乎）
• Shaft（Pixiv）

这些三方客户端有更为优秀的外观，更为可观的速度，以及某些诱人的功能。

手动养老

对 QQ 微信等压力大的软件启动 Scene 监视器，随时监测硬件状况以逼迫自己养老，防止 OOM。

CPU 方向

通用

推介以下两件套：Scene 、Moka。

Scene 可以调整 CPU~~，Moka 可以删除温控［注意：OPPO R11 一路下键即可，删不干净很正常，全删掉会有 Bug（比如爆音、打电话自动开免提、录屏时录不了系统内部声音）］~~，强烈不建议删除温控，而且移除温控之后毫无效果。

三方调度

Uperf 方案

刷入 Uperf Game Turbo、AsoulOpt

Uperf Game Turbo 可以较好地调节 CPU，使之在需要省电时省电、需要性能时高效。（注意：我们只需要 Uperf Game Turbo 的配置文件，而不需要其过分地教我们做事。为了避免其引起的一系列问题，请在刷入后将其禁用。）

AsoulOpt 可以调节线程，提高 CPU 效率。

CuprumTurbo Scheduler 方案

说这个东西可能令人眼前一黑，但如果说 CuToolBox，相信大多数人都耳熟能详。CuprumTurbo Scheduler 就是 CuToolBox 的模块版。

经过测试后发现其确实有助于提升流畅性；但未经长期测试，加之峰值功率与 Uperf Game Turbo 相比明显偏大，难以得出准确结论。

Tritium Fiage 方案

Tritium Fiage 是基于 CuprumTurbo Scheduler 的修改版，可以从酷安的鱼龄那里下载。

启用后建议将性能模式设为默认。功耗基本不会变，但流畅度会好很多。

Dex2oat

手动 dex2oat 可以提高冷启动速度并降低 CPU 和 RAM 占用，具体选哪一个模式请自行测试。

后台

对非必要软件关禁闭

使用小黑屋、雹等软件，以禁用方式冻结在后台死皮赖脸的软件。

调节所有软件后台活动

1. 在 Thanox 的后台启动和后台运行中对用户应用设置全不，在任务清理和乖巧模式中设置全部，随后排除 Shizuku、输入法、三方 Widget 等常驻后台的软件。
2. 切换过滤规则为系统，对软件商店等毒瘤适当设置。（我用类原生，没有经验，提供不了相关建议）
3. 添加模板，仅打开任务清理和乖巧模式（仅点亮这两个开关，其他均灭掉），并启用自动配置

注意

1. 对咕噜咕噜 Play 服务、咕噜咕噜服务框架和咕噜咕噜商店的操作可能会导致其它软件无法调用咕噜咕噜相关服务
2. 对下载器与浏览器打开乖巧模式会导致下载通知冻结
3. 对浏览器打开后台运行而关闭任务清理可能会导致其一直在后台吃内存

为必要软件开小灶

接消息

某些软件（比如微信 QQ 等通讯软件）要接消息，但如果一直挂后台占 RAM 太多，可在应用详情页：

1. 打开后台启动（否则开机不自启动）
2. 打开后台运行、后台保护，关闭任务清理（否则频繁被杀死）
3. 乖巧模式（减少后台占用）

监听

某些软件（比如 Robot36、Thanox 后台记录、Scene 动态切换、Shizuku）要能够一直执行下去并实时响应用户操作，还有一些软件（比如天气小组件）要频繁获取信息，可在应用详情页：

1. 打开后台启动（否则开机不自启动）
2. 打开后台运行、后台保护，关闭任务清理、乖巧模式（否则频繁被杀死）

效果

本文将介绍三种主流 Root（Magisk、KernelSU、APatch）的安装，并介绍它们的一些技巧提示。

开始之前，请确保您已经刷入了 TWRP 3.7.0、1170底包的系统，并有且只有一种可用的 Root 方式。

必备前置知识

救砖

• 救砖 | KernelSU
• 救砖 | APatch Docs
• logcat、dmesg、/proc/kmsg 等抓取日志的方法
• 基本的 Git 知识

内核切换方法

切换、更新、修改内核有三种方法：

1. 从别人那里要来 boot.img 刷入
2. 将内核镜像（.gz/.gz-dtb）用 AnyKernel3 刷入
3. 将内核镜像（Image）用 magiskboot 打包入 boot.img 刷入

Magisk

安装 Magisk

1. 下载 Magisk 最新版 APK 文件，并安装到手机中。
2. 打开 Magisk Manager，点击左上角的 “安装” 按钮，选择空白的 Boot 镜像文件，修补。
3. 使用 TWRP 备份 Boot 分区，刷入修补好的 boot.img 到 Boot 分区，然后重启手机。
4. 重启后会提示需要修复环境，不要点击修复，按返回键拒绝。选择安装，取消勾选“安装到 Recovery”，然后重启。

Magisk 注意事项

1. Wenhao 新版内核由于未知原因不适用 Magisk，将会导致手机随机重启入 EDL 模式或高通救援模式，并且无法使用微信视频通话和 QQ 视频通话，请勿尝试。
2. 修复 Magisk 运行环境与更新 Magisk 时，务必取消勾选 “安装到 recvoery” 这个选项，高版本 Magisk （26.1+）会默认启用这个选项，错误刷入后会导致 WLAN 无法打开以及 Recovery 无法进入。
   如果您不慎安装到了 Recovery，请提取卡刷包内的 boot.img 和 recovery.img 重新刷入对应分区，或者干脆重刷完整包。
3. “Ramdisk” 为 “否” 是正常的，是 R11 (s) 设备的特性，不影响 Magisk 功能。
4. 使用 Magisk Delta（后改名 Kitsune Mask）将难以在除 Kitsune 自己的群组之外的社区得到技术支持，也不需要且无法使用 Shamiko 和 ZygiskNext（包括衍生）。 不建议继续使用 Kitsune Mask，其不仅在社区内臭名昭著，而且已经停止更新。
5. Alpha 禁止在 Android 内修改 /system，介意勿用。但要知道：这十分有利于安全。

Magisk 技巧提示

1. Magisk APK 相当于刷机包。当 Magisk 出现 “掉 Root 权限”“获取不到 Root 权限”“Zygisk 反复注入失败” 等问题，而三方 Recovery 又可用时，您可以通过将 Magisk.apk 重命名为 Magisk.zip 并刷入来修复。
2. Magisk 有多个 Fork，各 Fork 各有不同。若您想切换不同的的 Fork，除了在三方 Recovery 中刷入 Magisk.zip 外，还可以在已有的 Magisk Manager 中授予将要安装的 Magisk Manager Root 权限，并重新启动准备安装的 Magisk Manager。此时准备安装的 Magisk Manager 应当有 “无法获取版本信息”“必须重新安装”“修复运行环境” 等提示，重新安装即可。

KernelSU

安装 KernelSU

在第三方 Recovery 中把 AnyKernel3-*.zip 刷入即可

KernelSU 注意事项

1. KernelSU 在 1.x 版本中移除了 non-GKI 支持，因此不适用于 R11 设备。R11 设备请使用 0.9.5 及以下版本。 R11 作为 non-GKI 设备应当使用 RKSU
2. KernelSU 在 0.9.3 版本中更改了管理器检测方式，在 ColorOS 6 上会引起卡二屏。请使用 0.9.2 及以下版本。
3. 安装模块超级慢的情况暂时无解。 MKSU 引入了 Magic Mount，可以缓解安装模块缓慢无比的情况。
4. KernelSU 禁止在 Android 内修改 /system，介意勿用。但要知道：这十分有利于安全。
5. KernelSU 没有申请 Root 权限的机制。在授予应用程序 Root 后，应用程序在调用时会自动获取 Root 权限且无任何提示。请仅授予可信的应用程序 Root 权限！
6. KernelSU 暂未有较好的隐藏挂载点泄漏的方法。 不建议使用 susfs。

APatch

安装 APatch

1. 下载 APatch 最新版 APK 文件，并安装到手机中。
2. 打开 APatch Manager，点击右上角的 “安装” 按钮，选择空白的 Boot 镜像文件，修补。
3. 使用 TWRP 备份 Boot 分区，刷入修补好的 boot.img 到 Boot 分区，然后重启手机。

APatch 注意事项

1. 更新 APatch 管理器后需进行两步更新：
   1. 点击主页面更新以更新系统补丁（APatch）
   2. 重新修补并刷写 Boot 分区以更新 KernelPatch
2. APatch 禁止在 Android 内修改 /system，介意勿用。但要知道：这十分有利于安全。
3. APatch 没有申请 Root 权限的机制。在授予应用程序 Root 后，应用程序在调用时会自动获取 Root 权限且无任何提示。请仅授予可信的应用程序 Root 权限！
4. 若您使用了他人修补的 boot.img，务必重新设置密钥！
5. Scene 及其附属模块暂不支持 APatch，请勿尝试安装。

APatch 技巧提示

1. 可通过使用内核模块 Cherish Peekaboo 隐藏一些挂载点。（作者：GarfieldHan，暂停更新）
2. 可通过特殊方法使用 Shamiko，但非常不建议。（作者：GarfieldHan）

推荐学习

自己编译内核

如果您对已有的内核不满意，想要自己修改一下；或者等不及更新，按捺不住追版本号的激动，那下面的内容正合您胃口。

编译内核是一项较为浩大的工程，所以我们用 Github CodeSpace 编译。当然，您也可以选择本地计算机。但是，使用 CodeSpace 有相当的优势：

1. 自带完美的、几乎无性能损耗的 Ubuntu，免除安装、调试系统的烦恼
2. Ubuntu 是较为常规、通用、可靠的 Linux 发行版，有助于避免在一些小众发行版上的问题
3. 编译内核很占 CPU、内存和磁盘 IO，会影响本地计算机的使用

启动！

Fork 自己中意的仓库，建立它的 CodeSpace，各项配置拉满。

环境搭建

首先，您需要准备好编译环境。

环境变量

设置必需的环境变量。

1
2
3
4
5

export ARCH="arm64"
export SUBARCH="arm64"
export PATH=$PATH:/path/to/gcc/bin
export CROSS_COMPILE=aarch64-xxxxxxxxxx
export OPPO_TARGET_DEVICE="MSM_nnnnn" # R11 MSM_16051，R11s MSM_17011

1
2
3
4
5

export ARCH="arm64"
export SUBARCH="arm64"
export PATH=$PATH:/path/to/clang/bin
export CROSS_COMPILE=aarch64-xxxxxxxxxx
export OPPO_TARGET_DEVICE="MSM_nnnnn" # R11 MSM_16051，R11s MSM_17011

编译

1
2
3

# 拉取子模块
git submodule init
git submodule update

1
2

make O=out sdm660-perf_defconfig
make -j$(nproc --all) O=out 2>&1 | tee kernel_log.log

1
2

make O=out sdm660-perf_defconfig CC=clang
make -j$(nproc --all) O=out CC=clang 2>&1 | tee kernel_log.log

打包内核

参考资料

• WenHao2130/android_kernel_oppo_sdm660
• 如何为非 GKI 内核集成 KernelSU | KernelSU
• [基础教程] 如何编译一个 ARM64 架构的自定义内核・tiann/KernelSU・Discussion #950
• [基础教程 2] 如何使用 AnyKernel 3 打包内核・tiann/KernelSU・Discussion #952
• 安装 | APatch Docs

拓展阅读

• osm0sis/AnyKernel3: AnyKernel, Evolved
• DTB 映像  |  Android 开源项目  |  Android Open Source Project

鸣谢

• Wenhao2130

机型概况

机子是 2017 年发布的 OPPO R11，CPU 是骁龙 660 AIE，运存为 4GB，闪存是严重磨损的 eMMC 64GB。电池是原装的 3000mAh 的（现在只有 2200mAh 了）。

绿厂只给到 Android 9 ColorOS 6，连暗色模式都没有，根本满足不了我的需求。于是，我决定刷机。

OPPO R11 目前主要由 CY 团队维护，故绝大多数资源来自 CY 团队的下载站。分享链接有密码，请自行加群获取。

刷机入门

在此，我们需要明确几个定义：

• 底层：是指基本的驱动等最重要、最基本的文件，即 “底包”。R11 (s) 系列底包版本号多为 X.nn、nnnn 或 nnnnnn 格式。由于并不总是能够提供三种版本号，请自行辨别。
• 系统：
  1. 字面意义上的系统，包括全部可被刷写的分区
  2. 分区名，通常指 System 分区，可能同时也包括 Boot 分区和 Vendor 分区
• A/C：为了避免歧义，本文中 Android 与 ColorOS 均使用全称而不简称为 A 或 C

解除 Fastboot 限制

由于在大多数稳定版系统中 OPPO 对 fastboot 进行了限制，所以我们必须降级或升级至合适的版本进行解锁 BootLoader 的操作。

无限制

若您的版本号为 A.01 / 170529 或 C.17 / 1170，恭喜，Fastboot 畅通无阻，您可直接开始解锁 BootLoader。

升级

若您的版本号小于 C.17 / 1170，则可以下载 R11_11_OTA_1170_all_PDZfMhjgV0q1_b68a39.ozip，在自带文件管理中打开，升级至 C.17 / 1170 以解除限制。

降级

相信决定对 OPPO R11 刷机的同学大多数应该更新到了比较新的系统版本吧？如果您的版本号为 C.19 / 1190，则必须采用降级法。由于此时手机处于严重受限状态，所以我们只能采用最底层的刷机方式 9008 刷机（这也是售后修手机的方法）进行降级操作。

1. 打上驱动
2. 下载 R11_11_A.01_170529（9008 线刷包，11、11t 可用）.7z 和 R11-MsmDownloadTool.exe，选择对应代号（R11 的代号为 16051）；手机关机，同时按下电源键 +音量++音量- 进入 EDL（9008 模式），连接手机至电脑，按照提示刷入即可。
3. A.01，启动！

切记保证数据线连接良好，慎防数据线意外松动。除此之外，基本不会出现什么问题。如果出现诸如 “握手失败”“握手超时” 之类的错误，请尝试重启电脑与手机、更换数据线或 USB 口、重装驱动，有条件的更换电脑。

解锁 BootLoader

1. 打开开发者选项
   打开手机，进入设置，找到 “关于手机” 或 “关于设备” 选项，找到 “版本号” 或 “型号 “一栏，并连续点击数次（通常需要点击 7 次），开发者模式即可成功开启。
2. 打开 OEM 解锁和 USB 调试开关
3. 下载 SDK Platform Tools，并解压到合适的位置
4. 手机连接电脑，重启到 fastboot（或执行 adb reboot fastboot），然后执行 fastboot oem unlock，终端应当提示 “unlocked”
5. 重启，手机应当有一橙色感叹号（< ! >），提示 “数据有危险”，并要求你访问g.co/ABH。若有，则解锁成功。

刷入第三方 Rec

1. 手机连接电脑，重启到 fastboot（或执行 adb reboot fastboot）
2. 电脑下载合适的 Recovery 镜像，执行 fastboot flash recovery twrp-x.x.x-xxxx.img

刷入第三方系统

1. 从第三方系统刷机包 (Third Party ROM) 内下载喜欢的包
2. 这些包大多是一体包，直接刷入就好

这里面引入了五套字体，每套字体 3 个或 9 个字重，共计需要加载 1000 ～ 2000 个字体文件。那么，这个网页的速度与性能，会差到什么程度？

由此，我们引出本文的话题：如何优化网站速度？

减少下载资源的数量

更多的文件意味着更长的加载用时与渲染用时，因此应慎重引入。以 Butterfly 主题为例，若不必需某些组件（如 abcjs），则应将其关闭。若不明确某些功能（如 Lazyload）的利弊关系，则也不应轻易启用。常见的有：

功能性附加组件

附加组件包括 abcjs，Mermaid，Katex/MathJax，Aplayer，Firework 等。这些东西若非必需，不应以多多益善为由开启。

1
2
3

# eg.
aplayerInject:
  enable: false

此外，还有诸如小挂件、弹窗等，同样有一定的性能需求，可能也会对页面带来负担。

预加载

在双方网速足够快时，开启它的作用似乎并不明显。但对于部署于 Github Pages 等国外平台建议开启。

1

instantpage: true

懒加载

在图床速度足够快时，开启它作用并不明显。

1
2

lazyload:
  enable: false

调节动画

很多朋友为了网页美观性往往会添加加载动画，但正如前面所说，只要有一条资源有问题，就会阻塞整个加载动画，致使网页迟迟显示不出有效内容。纵使是非全屏式动画（pace_css），也仿佛在提示用户 “嘿！我还没加载完呢！” 十分影响观感，建议关闭。

1
2

preloader:
  enable: false

但是开启转场动画可以掩盖加载时的闪烁，提高美观性。

1

enter_transitions: true

优化图片

图片作为媒体的重头戏，在网页上不可或缺。随着图片体积的增大，图片所带来的负担也不容小觑。优化图片的要做的是减小体积，其方法有：

1. 手动降低分辨率、位深、色彩精度之类
2. 使用工具进行无损或低损压缩
   参见：Butterfly 安裝文檔 (六) 進階教程 | Butterfly
3. 将 PNG，JPG 等格式转为 WeBP 或 Avif 格式
   此类图片发布日期较新，有许多新技术以及新特征（比如在保证质量不太差的前提下，最大程度压缩体积），适合网页使用
4. 将 Gif 换用 APNG 或 MP4
   Gif 不仅体积巨大，质量差，渲染还十分费力，不如直接用视频

保证资源加载畅通

保证性能良好

在引用资源前，应确保来源稳定可靠。若其速度不稳定或服务时好时坏，可能会导致卡加载动画或卡白屏。

应对资源和服务进行维护、监控或选择可靠的来源，引入前应进行多地 Ping/HTTP 测试，确保多地访问通畅。

若确因资金、政策、网络环境等原因不能保证服务时时可用，可考虑使用备用 URL 或 IP 属地判断等技术缓解。具体请参考 hexo-swpp、 Swpp Backends 官方文档 和一份新版配置文件。

使用合适的 CDN

打个比方，假如在上海收快递时，件儿从苏州还是美国发过来快？显然是苏州！CDN 也同理。市面上常用的公益 CDN（JSDelivr， UNPKG，CDNJS）等多没有大陆节点，使用此类 CDN，数据包往往要漂洋过海从大洋彼岸发过来，速度堪忧。

以 Butterfly  为例，可在配置中将 CDN 来源设为 custom 以使用可靠的国内 CDN：

1
2
3

CDN:
  third_party_provider: custom
  custom_format: https://registry.npmmirror.com/${name}/${version}/files/${file}

其它一些优秀的公益 CDN：

1
2
3
4
5
6
7
8
9
10

# Custom format
## NPM(推荐，CDNJS 并不总是提供最新版本的包)
# custom_format: https://cdn.jsdmirror.com/npm/${name}@${version}/${file}
# custom_format: https://npm.webcache.cn/${name}@${version}/${file}
custom_format: https://registry.npmmirror.com/${name}/${version}/files/${file}
# custom_format: https://npm.akass.cn/${name}@${version}/${file}
## CDNJS
# custom_format: https://s4.zstatic.net/ajax/libs/${cdnjs_name}/${version}/${min_cdnjs_file}
# custom_format: https://cdnjs.webstatic.cn/ajax/libs/${cdnjs_name}/${version}/${min_cdnjs_file}
# custom_format: https://sf.akass.cn/${cdnjs_name}/${version}/${min_cdnjs_file}

若国内源无法包含所有所需文件，还可以给某资源设定单独链接。例如：

1
2
3

CDN:
  option:
    busuanzi: https://cn.vercount.one/js

若站点面向全球用户，则可选择 CDN 竞速等策略。具体按可以参见 hexo-swpp、 Swpp Backends 官方文档 和一份新版配置文件。

压缩文件

HTML/JS/CSS 文件中的回车、部分空格、注释等仅起提高可读性的作用，却仍占用相当大体积，因此应将其删去。

Gulp

参见网站加载速度优化方案总结 | 山岳库博

Hexo 插件

1

npm install hexo-html-minifier hexo-clean-css hexo-uglify --save

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

uglify:
  mangle: true
  output:
  compress:
  exclude:
    - "*.min.js"

clean_css:
  exclude:
    - "*.min.css"

html_minifier:
  collapseBooleanAttributes: true
  collapseWhitespace: true
  ignoreCustomComments: [!!js/regexp /^\s*more/]
  removeComments: true
  removeEmptyAttributes: true
  removeScriptTypeAttributes: true
  removeStyleLinkTypeAttributes: true
  minifyJS: true
  minifyCSS: true

1

npm install hexo-yam --save

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

minify:
  enable: true
  previewServer: true
  html:
    enable: true
    exclude:
  css:
    enable: true
    exclude:
  js:
    enable: true
    exclude:
      - "*.min.js"
  svg:
    enable: true
    include:
      - "*.svg"
  gzip:
    enable: false
  brotli:
    enable: false
  xml:
    enable: false
    include:
      - "*.xml"
  json:
    enable: true
    include:
      - "*.json"
  zstd:
    enable: false

缓存

部分服务器是没有缓存功能的，这意味着每次访问都需要从服务器下载资源，既浪费流量，又拉长加载时间，而 ServiceWorker 就解决了这一难题。ServiceWorker 可以对缓存进行合理调度，减少内容的下载量，对于速度提升十分明显。

具体部署过程此处不多讲，请参见 hexo-swpp、 Swpp Backends 官方文档 和一份新版配置文件。

一级标题

二级标题

三级标题

四级标题

五级标题

六级标题

粗体 斜体 粗斜体 正常 删除线

单行块引用

多个段落的块引用

多个段落的块引用

嵌套块引用

嵌套块引用

带有其它元素的块引用

带有其它元素的块引用

带有其它元素的块引用

带有其它元素的块引用

1. 有序列表
2. 有序列表
3. 有序列表
   1. 有序列表
   2. 有序列表
4. 有序列表

• 无序列表
• 无序列表
• 无序列表
  • 无序列表
  • 无序列表
• 无序列表

单行代码块 with Both Chines and English Text

分割线

链接

链接（带有标题）

https://www.lynx3.top/

email@example.com

带格式化的链接

Markdown 扩展语法

表格

任务列表

• 完善 Markdown 基础测试
• 引入代码高亮测试
• 修复 KaTeX 溢出问题
• 调整主题 CSS 样式

折叠块

下划线与名词解释

这是 带有下划线的文本，这是 插入的文本。

Hexo

快速、简洁且高效的博客框架

Butterfly

一个基于 Hexo 的高颜值且功能强大的主题

代码框

编译语言

C++

来源：https://raw.githubusercontent.com/argvchs/fastio/master/fastio.hpp

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472

#include <algorithm>
#include <cctype>
#include <cmath>
#include <cstddef>
#include <cstdio>
#include <cstring>
#include <string>
#include <string_view>
#include <type_traits>
namespace fastio {
namespace symbols {
enum symbol {
    endl,
    ends,
    flush,
    bin,
    oct,
    dec,
    hex,
    left,
    right,
    boolalpha,
    noboolalpha,
    showbase,
    noshowbase,
    showpoint,
    noshowpoint,
    showpos,
    noshowpos,
    ws,
    uppercase,
    lowercase,
    fixed,
    defaultfloat,
    reset
};
struct setbase {
    int base;
    setbase(int n) : base(n) {}
};
struct setfill {
    char fill;
    setfill(char c) : fill(c) {}
};
struct setprecision {
    int precision;
    setprecision(int n) : precision(n) {}
};
struct setw {
    int width;
    setw(int n) : width(n) {}
};
} // namespace symbols
namespace interface {
using i64 = long long;
using u64 = unsigned long long;
using i128 = __int128;
using u128 = unsigned __int128;
template <typename T>
constexpr bool is_signed_v =
    (std::is_integral_v<T> && std::is_signed_v<T>) || std::is_same_v<T, i128>;
template <typename T>
constexpr bool is_unsigned_v =
    (std::is_integral_v<T> && std::is_unsigned_v<T>) || std::is_same_v<T, u128>;
template <typename T> constexpr bool is_integral_v = is_signed_v<T> || is_unsigned_v<T>;
template <typename T> constexpr bool is_floating_v = std::is_floating_point_v<T>;
template <typename T> struct make_unsigned : public std::make_unsigned<T> {};
template <> struct make_unsigned<i128> : public std::type_identity<u128> {};
template <> struct make_unsigned<u128> : public std::type_identity<u128> {};
template <typename T> using make_unsigned_t = typename make_unsigned<T>::type;
struct noncopyable {
    noncopyable() = default;
    virtual ~noncopyable() = default;
    noncopyable(const noncopyable &) = delete;
    noncopyable &operator=(const noncopyable &) = delete;
};
class istream : public noncopyable {
  private:
    int base = 10;
    bool unget = false, eof = false, fail = false;
    char chr = '\0';
    static bool isssign(char c) { return isspace(c) || c == '+' || c == '-'; }
    int todigit(char c) {
        if (::isdigit(c)) return c - '0';
        if (isupper(c)) return c - 'A' + 10;
        if (islower(c)) return c - 'a' + 10;
        return base;
    }
    bool isdigit(char c) { return todigit(c) < base; }
    virtual char vget() = 0;
  public:
    char get() {
        if (!unget)
            if ((chr = vget()) == EOF) eof = true;
        unget = false;
        return chr;
    }
    istream &get(char &c) {
        c = get();
        return *this;
    }
    explicit operator bool() { return !fail; }
    bool operator!() { return fail; }
    template <typename T, std::enable_if_t<is_integral_v<T>, int> = 0>
    istream &operator>>(T &n) {
        n = 0;
        bool f = false;
        while (isssign(get()) && !eof)
            if (chr == '-' && is_integral_v<T>) f = !f;
        if (eof) return fail = true, *this;
        unget = true;
        while (isdigit(get())) n = n * base + todigit(chr);
        if (f) n = -n;
        unget = true;
        return *this;
    }
    template <typename T, std::enable_if_t<is_floating_v<T>, int> = 0>
    istream &operator>>(T &n) {
        n = 0;
        bool f = false;
        while (isssign(get()) && !eof)
            if (chr == '-') f = !f;
        if (eof) return fail = true, *this;
        unget = true;
        while (isdigit(get())) n = n * base + todigit(chr);
        if (chr == '.') {
            i64 pow = 1;
            while (isdigit(get())) n += todigit(chr) / (T)(pow *= base);
        }
        if (f) n = -n;
        unget = true;
        return *this;
    }
    istream &operator>>(char &c) {
        c = '\0';
        while (isspace(get()) && !eof);
        if (eof) return fail = true, *this;
        c = chr;
        return *this;
    }
    istream &operator>>(bool &f) {
        i64 n;
        *this >> n;
        f = (bool)n;
        return *this;
    }
    istream &operator>>(char *s) {
        s[0] = '\0';
        int len = 0;
        while (isspace(get()) && !eof);
        if (eof) return fail = true, *this;
        unget = true;
        while (isgraph(get())) s[len++] = chr;
        unget = true, s[len] = '\0';
        return *this;
    }
    istream &operator>>(std::string &s) {
        s.clear();
        while (isspace(get()) && !eof);
        if (eof) return fail = true, *this;
        unget = true;
        while (isgraph(get())) s.push_back(chr);
        unget = true;
        return *this;
    }
    istream &operator>>(symbols::symbol a) {
        switch (a) {
        case symbols::bin: base = 2; break;
        case symbols::oct: base = 8; break;
        case symbols::dec: base = 10; break;
        case symbols::hex: base = 16; break;
        case symbols::ws:
            while (isspace(get()) && !eof);
            unget = true;
            break;
        default: base = 10;
        }
        return *this;
    }
    istream &operator>>(symbols::setbase a) {
        base = std::max(std::min(a.base, 36), 2);
        return *this;
    }
    istream &ignore(char end = '\n') {
        while (get() != end && !eof);
        if (eof) return fail = true, *this;
        return *this;
    }
    istream &getline(char *s, char end = '\n') {
        s[0] = '\0';
        int len = 0;
        if (eof) return fail = true, *this;
        while (get() != end && !eof) s[len++] = chr;
        if (s[len - 1] == '\r' && end == '\n') --len;
        s[len] = '\0';
        return *this;
    }
    istream &getline(std::string &s, char end = '\n') {
        s.clear();
        if (eof) return fail = true, *this;
        while (get() != end && !eof) s.push_back(chr);
        if (s.back() == '\r' && end == '\n') s.pop_back();
        return *this;
    }
    istream &get(char *s, char end = '\n') {
        getline(s, end);
        unget = true;
        return *this;
    }
    istream &get(std::string &s, char end = '\n') {
        getline(s, end);
        unget = true;
        return *this;
    }
};
class ostream : public noncopyable {
  private:
    int base = 10, precision = 6, width = 0;
    i64 eps = 1e6;
    bool adjust = true, boolalpha = false, showbase = false, showpoint = false,
         showpos = false, kase = false, fixed = false;
    char setfill = ' ';
    static i64 qpow(i64 n, int m) {
        i64 ret = 1;
        for (int i = m; i; i >>= 1, n *= n)
            if (i & 1) ret *= n;
        return ret;
    }
    void fill(int n) {
        if (width > n) vfill(setfill, width - n);
        width = 0;
    }
    char toalpha(int n) {
        if (n < 10) return n + '0';
        return n - 10 + (kase ? 'A' : 'a');
    }
    virtual void vput(char) = 0;
    virtual void vputs(const char *, int) = 0;
    virtual void vfill(char, int) = 0;
    virtual void vflush() = 0;
  public:
    void put(char c) { vput(c); }
    template <typename T, std::enable_if_t<is_integral_v<T>, int> = 0>
    ostream &operator<<(T n) {
        static char buf[105];
        char *p = buf + 100, *q = buf + 100;
        bool f = n < 0;
        if (f) n = -n;
        make_unsigned_t<T> m = n;
        if (!m) *p-- = '0';
        while (m) *p-- = toalpha(m % base), m /= base;
        if (showbase) switch (base) {
            case 2: *p-- = kase ? 'B' : 'b', *p-- = '0'; break;
            case 8: *p-- = '0'; break;
            case 16: *p-- = kase ? 'X' : 'x', *p-- = '0'; break;
            }
        if (!f) {
            if (showpos && is_signed_v<T>) *p-- = '+';
        } else *p-- = '-';
        if (adjust) fill(q - p);
        vputs(p + 1, q - p);
        if (!adjust) fill(q - p);
        return *this;
    }
    template <typename T, std::enable_if_t<is_floating_v<T>, int> = 0>
    ostream &operator<<(T n) {
        static char buf1[105], buf2[105];
        if (std::isinf(n)) {
            if (n > 0) {
                if (showpos) *this << (kase ? "+INF" : "+inf");
                else *this << (kase ? "INF" : "inf");
            } else *this << (kase ? "-INF" : "-inf");
            return *this;
        }
        if (std::isnan(n)) return *this << (kase ? "NAN" : "nan");
        char *p1 = buf1 + 100, *q1 = buf1 + 100, *p2 = buf2 + 100, *q2 = buf2 + 100;
        bool f = n < 0;
        if (f) n = -n;
        i64 m1 = std::floor(n), m2 = std::round((n - m1) * eps);
        int len = precision;
        if (m2 >= eps) ++m1, m2 = 0;
        if (!m1) *p1-- = '0';
        while (m1) *p1-- = toalpha(m1 % base), m1 /= base;
        while (len--) *p2-- = toalpha(m2 % base), m2 /= base;
        if (showbase) switch (base) {
            case 2: *p1-- = kase ? 'B' : 'b', *p1-- = '0'; break;
            case 8: *p1-- = '0'; break;
            case 16: *p1-- = kase ? 'X' : 'x', *p1-- = '0'; break;
            }
        if (!f) {
            if (showpos) *p1-- = '+';
        } else *p1-- = '-';
        if (!fixed)
            while (*q2 == '0' && p2 != q2) --q2;
        if (showpoint || p2 != q2) *p2-- = '.';
        if (adjust) fill((q1 - p1) + (q2 - p2));
        vputs(p1 + 1, q1 - p1);
        vputs(p2 + 1, q2 - p2);
        if (!adjust) fill((q1 - p1) + (q2 - p2));
        return *this;
    }
    ostream &operator<<(char c) {
        if (adjust) fill(1);
        vput(c);
        if (!adjust) fill(1);
        return *this;
    }
    ostream &operator<<(const char *s) {
        int n = strlen(s);
        if (adjust) fill(n);
        vputs(s, n);
        if (!adjust) fill(n);
        return *this;
    }
    ostream &operator<<(const std::string &s) {
        int n = s.size();
        if (adjust) fill(n);
        vputs(s.data(), n);
        if (!adjust) fill(n);
        return *this;
    }
    ostream &operator<<(std::string_view sv) {
        int n = sv.size();
        if (adjust) fill(n);
        vputs(sv.data(), n);
        if (!adjust) fill(n);
        return *this;
    }
    ostream &operator<<(bool f) {
        if (f) {
            if (boolalpha) *this << (kase ? "TRUE" : "true");
            else *this << '1';
        } else {
            if (boolalpha) *this << (kase ? "FALSE" : "false");
            else *this << '0';
        }
        return *this;
    }
    ostream &operator<<(const void *p) {
        int n = base;
        bool f = showbase;
        base = 16, showbase = true;
        *this << (u64)p;
        base = n, showbase = f;
        return *this;
    }
    ostream &operator<<(std::nullptr_t) {
        return *this << (kase ? "NULLPTR" : "nullptr");
    }
    ostream &operator<<(symbols::symbol a) {
        switch (a) {
        case symbols::endl: vput('\n'); break;
        case symbols::ends: vput(' '); break;
        case symbols::flush: vflush(); break;
        case symbols::bin: eps = qpow(base = 2, precision); break;
        case symbols::oct: eps = qpow(base = 8, precision); break;
        case symbols::dec: eps = qpow(base = 10, precision); break;
        case symbols::hex: eps = qpow(base = 16, precision); break;
        case symbols::left: adjust = false; break;
        case symbols::right: adjust = true; break;
        case symbols::boolalpha: boolalpha = true; break;
        case symbols::noboolalpha: boolalpha = false; break;
        case symbols::showbase: showbase = true; break;
        case symbols::noshowbase: showbase = false; break;
        case symbols::showpoint: showpoint = true; break;
        case symbols::noshowpoint: showpoint = false; break;
        case symbols::showpos: showpos = true; break;
        case symbols::noshowpos: showpos = false; break;
        case symbols::uppercase: kase = true; break;
        case symbols::lowercase: kase = false; break;
        case symbols::fixed: fixed = true; break;
        case symbols::defaultfloat: fixed = false; break;
        default:
            base = 10, precision = 6, width = 0, eps = 1e6;
            adjust = true;
            boolalpha = showbase = showpoint = showpos = kase = fixed = false;
            setfill = ' ';
        }
        return *this;
    }
    ostream &operator<<(symbols::setbase a) {
        base = std::max(std::min(a.base, 36), 2);
        eps = qpow(base, precision);
        return *this;
    }
    ostream &operator<<(symbols::setfill a) {
        setfill = a.fill;
        return *this;
    }
    ostream &operator<<(symbols::setprecision a) {
        precision = std::max(a.precision, 0);
        eps = qpow(base, precision);
        return *this;
    }
    ostream &operator<<(symbols::setw a) {
        width = std::max(a.width, 0);
        return *this;
    }
};
} // namespace interface
const int SIZ = 0xfffff;
class istream : public interface::istream {
  private:
    char buf[SIZ], *p = buf, *q = buf;
    virtual char vget() final {
        if (p == q) {
            int len = fread(buf, 1, SIZ, stream);
            if (!len) return EOF;
            p = buf, q = buf + len;
        }
        return *p++;
    }
  protected:
    FILE *stream = stdin;
  public:
    virtual ~istream() { fclose(stream); }
};
class ifstream : public istream {
  public:
    explicit ifstream(FILE *p) { istream::stream = p; }
    explicit ifstream(const char *s) { istream::stream = fopen(s, "r"); }
};
class ostream : public interface::ostream {
  private:
    char buf[SIZ], *p = buf;
    virtual void vput(char c) final {
        if (p - buf >= SIZ) vflush();
        *p++ = c;
    }
    virtual void vputs(const char *s, int n) final {
        int used = p - buf, len = 0;
        while (n - len + used >= SIZ) {
            memcpy(buf + used, s + len, SIZ - used);
            p = buf + SIZ;
            vflush();
            len += SIZ - used, used = 0;
        }
        memcpy(buf + used, s + len, n - len);
        p = buf + used + n - len;
    }
    virtual void vfill(char c, int n) final {
        int used = p - buf, len = 0;
        while (n - len + used >= SIZ) {
            memset(buf + used, c, SIZ - used);
            p = buf + SIZ;
            vflush();
            len += SIZ - used, used = 0;
        }
        memset(buf + used, c, n - len);
        p = buf + used + n - len;
    }
    virtual void vflush() final {
        fwrite(buf, 1, p - buf, stream);
        p = buf;
        fflush(stream);
    }
  protected:
    FILE *stream = stdout;
  public:
    virtual ~ostream() {
        vflush();
        fclose(stream);
    }
};
class ofstream : public ostream {
  public:
    explicit ofstream(FILE *p) { ostream::stream = p; }
    explicit ofstream(const char *s) { ostream::stream = fopen(s, "w"); }
};
static istream is;
static ostream os;
}; // namespace fastio