告诉你的孩子，十八岁前，不会让他们因为钱而感到窘迫，这是为了塑造自信的性格，但十八岁后，会让他们因为钱而感到烦恼，这是为了培养独立的金钱观。
封面图片是由豆包 AI 生成的图片，一只望向星空的小狗。
转载自我自己的微信公众号，欢迎关注。
人的能力是有限的，所以只可能在一个有限的范围内做出正确的决定，找到这个边界，认清这个边界，并在试图尝试在边界外发表观点时保持谦卑。
封面图片来自豆包 AI。
转载自我自己的微信公众号，欢迎关注。
很早之前就想写这篇关于 Skills 的介绍，但一直犹豫，Skills 的生态变化太快，我怕写完的时候，它已经又是另一副面孔了。不过想了想，核心机制是稳定的，变了的大多是表面，所以还是写吧。
上一篇我们聊了 CLAUDE.md，它是厨房操作规范，静态的规则和偏好，写一次天天生效。但你在后厨干活，光有规范还不够。炒宫保鸡丁有炒宫保鸡丁的套路，先腌肉、再调汁、最后大火爆炒，这是一套流程，不是一条规则。你没法把 ”宫保鸡丁做法” 塞进一条备忘录里，因为它不是偏好，而是一套有序的操作。
Skills，就是把这套流程打包起来。Claude 通过学习 skill 中的描述，就知道该按什么顺序、用什么标准来操作。
CLAUDE.md 能做的事很明确，告诉 Claude 你的口味偏好和项目规矩。但它有个硬伤，只能表达静态规则，无法封装多步骤工作流 或特定领域知识 。
你可以在 CLAUDE.md 里写 ”代码提交前必须过审查”，但并不适合详细写清楚 ”审查具体分几步、每步看什么、输出什么格式的报告”。这就像告诉大厨 ”菜要好吃”，但没给他菜谱，方向对了，操作模糊。
Skills 的本质，就是将一套标准操作流程（SOP）打包成 Claude 可调用、可重复执行的 ”技能单元”。
一个 Skill 就是一个包含 SKILL.md 文件的目录。结构很简单：
1 | .claude/skills/code-review/ |
SKILL.md 的格式也不复杂，核心就是一段 YAML frontmatter 加正文，举个例子：
1 | --- |
frontmatter（两个 --- 之间的 YAML）定义技能的元数据。name 是标识符，必须和目录名一致；description 是唯一触发信号，Claude 只靠它来决定是否自动调用这个 skill。写得太模糊，Claude 不知道什么时候该用；写得太窄，又可能漏掉该触发的场景。
既然 description 是自动触发的唯一依据，值得花点篇幅说说怎么写。
Claude 有一个倾向：不触发（undertrigger）。它宁可不用 skill 也不要误用，所以你的 description 得 ”推” 它一把。具体来说，description 里应该同时包含两件事：这个 skill 做什么 ，以及 什么时候该用它 。
举个糟糕的例子：
1 | description: Code review skill |
太简短了，Claude 不知道该在什么场景下触发。更好的写法：
1 | description: Use when a major project step has been completed and needs |
这个写法明确了触发场景（”项目里程碑完成时”），Claude 就知道该在什么时候主动调用它。
还有一个常见的误区：把 ”什么时候用” 的信息写在 SKILL.md 的正文中，而不是 description 里。这是没用的，因为正文在触发之前 Claude 根本看不到。关于这一点，下一节会解释原因。
除了 name 和 description，还有一些可选字段，我挑几个常用的：
| 字段 | 用途 |
|---|---|
| model | 指定执行该 skill 时使用的模型，可选 haiku、sonnet、opus，默认继承当前会话的模型 |
| allowed-tools | 预授权的工具列表，减少权限弹窗。支持通配符如 Bash(git:*) |
| argument-hint | 给用户的参数提示，比如 [pr-number] [priority]，会在斜杠命令菜单中显示 |
| disable-model-invocation | 设为 true 后，这个 skill 只能由用户手动 /skill-name 触发，Claude 不会自动调用它 |
其中 model 字段挺实用。如果一个 skill 只是做简单的格式化，指定 haiku 就够了，没必要动用 opus，省 Token 又快。如果是要做深度推理的代码审查，就指定 opus。
正常情况下，Claude 每次调用工具都会弹权限确认，如果你的 skill 需要频繁执行 git 命令，弹窗能把人弹崩溃。在 frontmatter 里写上 allowed-tools: Bash(git:*)，这类操作就自动放行，不再打扰你。
disable-model-invocation 适合那些必须由人主动发起的 skill。比如一个会删除分支的清理 skill，你肯定不想让 Claude 自作主张的触发，加了这个字段就锁死了，只有你亲手 /clean-branches 才会执行。
Skills 有两种触发方式。
自动触发 ：Claude 会根据你提的问题，自动判断是否需要调用某个 skill。这个判断依赖于 SKILL.md 中的 description 字段，所以我说 description 要写好。
手动触发 ：在对话中使用 /skill-name，这就是一个斜杠命令。比如你想让 Claude 用 code-review 技能来审查代码，直接输入：
1 | /code-review 请审查 app.py |
在 Claude 会话中输入 /skills，就会列出所有已加载的 Skills 清单。
如果你还没有安装任何 skill，这里输出就是空的。后边我会介绍如何安装 skill。
在 ~/.claude/commands/ 目录，里面放的是 ”命令”，用 /command-name 触发。Skills 和 Commands 共享同一套触发机制，区别只在文件布局。.claude/commands/ 是旧格式，.claude/skills/name/SKILL.md 是新格式，两者加载方式完全一样。
对于用户来说，skill 就是一个斜杠命令。在 Claude 会话中输入 /，会出现一个命令菜单，你所有的 skill 都列在里面，description 就是菜单里显示的说明文字。所以 description 不只是给 Claude 看的触发信号，也是给人看的说明，写清楚点，两方都受益。
这是 Skills 机制里最精巧的设计，也是很多人忽略的部分。
Claude 对 Skill 的加载分三层，逐层递进：
第一层：元数据（始终在上下文中）。 每次会话启动时，Claude 会加载所有 skill 的 name 和 description，组成一个可用技能清单。这一层的体积很小，每个 skill 大概 100 词左右，但它是 Claude 判断 ”该不该用这个 skill” 的唯一依据。
第二层：SKILL.md 正文（触发时加载）。 当 Claude 决定调用某个 skill，或者用户用 /skill-name 手动触发时，SKILL.md 的完整正文才被加载到上下文中。这就是为什么我说 ”什么时候用” 的信息必须写在 description 里，而不是正文里，正文 Claude 在触发之前根本看不到。
第三层：附属资源（按需加载）。 skill 目录下可以有 scripts/、references/、assets/ 等子目录，里面放脚本、参考文档、模板文件。这些内容不会自动加载，只有 SKILL.md 的正文里指示 Claude 去读的时候，才会被拉进上下文。而且脚本可以直接执行，不必先加载源码。
这个三层设计解决了一个矛盾：你想让 Claude 知道很多技能的存在，但又不想把所有技能的完整内容都塞进上下文。这就是渐进式披露。
理解了这个机制，几个最佳实践就自然浮现了：description 要写清触发场景；SKILL.md 正文控制在 500 行以内，超出的内容拆到 references/ 里；别在正文里藏触发条件，Claude 看不到。
虽然 SKILL.md 的格式并不复杂，但写一份好的技能描述需要仔细推敲，description 越精确，Claude 触发和执行的准确度也就越高。
好消息是，你不必手动写。后面我会介绍怎么让 Claude 帮你生成。
Skills 有三种存放位置，同时存在时将按优先级从高到低覆盖，高优先级的同名 skill 会覆盖低优先级。
| 位置 | 路径 | 是否提交 Git | 适用场景 |
|---|---|---|---|
| 项目 Skills | .claude/skills/ | 提交 | 团队共享的项目特定技能 |
| 个人 Skills | ~/.claude/skills/ | 不提交 | 个人常用技能 |
| 插件 Skills | ~/.claude/plugins/` | 不提交 | 插件绑定的专用技能 |
个人技能跟着你走，项目技能跟着仓库走，插件技能跟着社区走。如果你在个人目录和项目目录各放了一个同名的 skill，项目级的会优先生效，这和 CLAUDE.md 的层级逻辑一致，近的覆盖远的。
不必什么都自己写。社区里已经有不少经过打磨的技能，拿来改改就能用：
| Skill 名称 | 功能 |
|---|---|
| code-review | 按团队规范审查代码，输出结构化报告 |
| brainstorming | 是 superpower plugin 的一个 skill，在社区非常热门，它帮助你梳理技术思路和生成 spec 文档 |
| grill-me | 是 mattpocock 维护的一个 skill，它可以让 Claude 扮演任何角色，通过多次挖掘式对话来启发你的思考 |
| find-skills | 它可以帮助你找到适合你的技能，也会在交互时自动推荐社区的 skill |
| skill-creator | 它可以帮你编写自己的 skill，下边会介绍怎么手工开发 skill |
| pptx | 这是 Anthropic 官方的一个 skill，可以帮助你生成 PPT |
| frontend-design | 这也是 Anthropic 官方提供的 skill，它可以帮助你设计前端界面 |
这些 skill 都开源在 GitHub 上。你也可以通过 find-skills 来找到自己需要的 skill 或者直接访问 skills.sh 来查看所有可用的 skill。
顺便提一嘴，插件（plugin）是对一些 skills、Hooks 等的封装，让它们可以在 Claude Code 中以插件的形式安装使用。Claude 有个命令是 /plugin，可以用它直接安装一个社区插件包。
其实不需要安装器，也不需要包管理器。一个 Skill 就是一个包含 SKILL.md 的目录。所谓安装，就是把那个目录放到 Claude Code 约定好的位置。这就是整个过程。
前文提过 Skills 的三个存放位置：个人目录 ~/.claude/skills/、项目目录 .claude/skills/、以及通过插件安装。个人目录适合放通用的技能，不管打开哪个项目都能用；项目目录适合放跟项目绑定的技能，跟着仓库走。你要做的只是把 skill 文件夹复制到对应的路径下。
不过，这种手动复制粘贴的办法还是太原始了。程序员都是 “偷懒” 的一帮人，所以能用工具就不动手。
在一些插件或 skill 开源仓库中，会介绍怎么一键安装。最常见的方法是使用 skills.sh 安装器，它通过 npx 运行，比如安装 mattpocock 的 skills 包：
1 | npx skills@latest add mattpocock/skills |
其中 mattpocock/skills 是 GitHub 上的一个仓库 https://github.com/mattpocock/skills，包含了多个 skill。
若想要安装插件，可以在 Claude Code 中使用 /plugin 命令，比如：
1 | /plugin install superpowers@claude-plugins-official |
这是 superpowers 插件包，一个社区上很火的 AI Agent 扩展。
安装完毕后，重启 Claude Code 后在会话中输入 /skills，就能看到新安装的 skill 出现在列表里了。
就这样。没有编译步骤，没有依赖解析，没有注册中心。Skill 就是一份自然语言写成的操作手册，Claude Code 启动时扫描指定目录，找到 SKILL.md 就加载元数据，触发时读正文。
不过需要明确的一点是，安装第三方 skill 之前，建议先扫一眼它的 SKILL.md 内容，重点看里面有没有 Bash 命令。如果看到 curl 往外部地址发数据，就该警惕了，有可能会涉及到信息安全问题。这一点的详细讨论放在后边的文章中。
除了安装现成的 skill，也许有时你想要一个高度定制化的版本，比如想把公司内的一些指导经验做成 skill。
让我们来创建一个实际的 skill 来演示这个过程。
开始之前，推荐先安装 skill-creator ，它可以指导 Claude code 生成 skill，可以理解成是一种”skill 生成器”。
在 Claude 会话中输入：
1 | 请帮我创建一个 SKILL， |
注意这里的描述方式，我不仅说了 ”生成测试”，还具体说了覆盖哪些场景、文件怎么命名、放在哪里。描述越具体，生成出来的 skill 质量越高。
Claude 会分析你的描述，生成完整的 SKILL.md 文件并保存到 .claude/skills/pytest-gen/ 目录下。你可以要求它修改，比如 ”增加 mock 数据库的示例”，直到满意为止。
虽然 Claude 能帮你生成 SKILL.md，但生成的质量取决于你描述得有多精确，垃圾进，垃圾出。花时间想清楚你要什么，比生成后反复修改要高效得多。
优先使用已有的公共 skill，不要重复造轮子。
定制优于从头写，如果公共技能不完全符合需求，复制到本地后让 Claude 修改它。
注意安全，安装第三方技能前，快速查看其 SKILL.md 内容，确认它不会做你不想让它做的事。
另外，可以用 /skills 命令随时查看当前激活的 Skills 清单，确认你想要的技能确实已经加载。
我自己也整理维护了一套 skills 包，把一些社区热门的 skills 整合在一起，做一些本土化定制，也方便一键安装。如果你感兴趣也可以去看看：https://github.com/P2Tree/ai-agent
其实说实话，Claude Code 本身的能力已经很强了，它在更新过程中，也在不断融合一些常用的 skill 到系统中，所以在我看来，Claude Code 自己就能做到 80 分，安装恰当的 skill 和编写合适的 CLAUDE.md 后，可以做到 95 分，这是一个锦上添花的事情。
接下来，我计划介绍下 Claude Code 这种全托管式 AI Coding，和 Chat 形式的 “传统” vibe coding 相比，最大的优势来源自哪里。当你想让它帮你查 GitHub 上的 PR、查数据库里的数据、或者写个邮件并发出去时，它是怎么做的。
下一篇，我们看看怎么用 MCP 给大厨接通连接外部世界的电话线。
封面图片来自豆包 AI。
本文同步发布在知乎账号下：Claude Code 实践指南（三）：组织 Skills 系统
当把 Claude Code 用到一个新项目时，期待满满地让它帮忙写代码，结果发现我们可能反复在和它强调一些无聊的问题，比如写代码用什么规范，和后端怎么通信，写完代码要加测试用例。强调完，它当时记住了，但很快又会再犯。上下文一压缩，很多要求都会忘记。
一个下午，感觉用 Claude Code 写代码，还不如自己动手写。
其实，是因为你少做了一件事：把规矩写下来，写进 CLAUDE.md。
想象你后厨的米其林大厨有个怪毛病：每天早上醒来，他对厨房的一切都丧失记忆。不知道调料架在哪，不知道你们家不吃辣，甚至连刀在哪都得你重新指一遍。
幸运的是，你可以准备一份”厨房操作规范”。每天大厨到岗，先读完规范再干活。规范里写了口味偏好、食材禁忌、操作规矩等。写一次，天天生效。
CLAUDE.md，就是这份规范。它是一个普通的 Markdown 文件，你可以像写便签一样用中文（或英文）写下你想让 Claude 记住的所有规则。
虽然 CLAUDE.md 写一次就永久生效，但写得不准反而会误导 Claude，所以写得精比写得多更重要。
Claude Code 的每次会话都是无状态的。你敲下 claude 回车的那一刻，是一个全新的”空白大脑”在等你。你之前教过它什么？统统不记得了。
CLAUDE.md 会在每次会话启动时自动加载到系统提示词（System Prompt） 中。这就好比大厨每天到岗第一件事就是读你的厨房规范，不读不开火。
这里有一个很容易被忽视的关键机制：即使在会话中使用了 /compact 压缩上下文，CLAUDE.md 也会从磁盘重新读取并重新注入。也就是说，它里面的规则永远不会因为上下文压缩而丢失。
对比一下就明白了：你在对话中口头告诉 Claude “我们项目用 2 空格缩进”，一旦上下文被压缩，这条规则可能就没了。但如果你把它写进 CLAUDE.md，压缩之后它会自动回来。
口头指令是沙上建塔，CLAUDE.md 才是刻石为碑。
不过，CLAUDE.md 只能记住静态规则，你在上一轮会话中讨论过的设计决策、踩过的坑，它会忘记。
社区有一个叫 claude-mem 的工具，用 Hooks 和向量数据库把跨会话的对话记忆持久化下来，算是从另一个角度补了这个缺口。第六篇会简单介绍。
Claude Code 会从当前目录向上查找，并合并加载 多个位置的 CLAUDE.md。这就好比你家厨房有一份总规范，每个灶台还能贴自己的小纸条，大厨会把所有纸条都看一遍，然后综合执行。
| 层级 | 文件路径 | 是否提交 Git | 用途 |
|---|---|---|---|
| 全局 | ~/.claude/CLAUDE.md | 不提交 | 个人偏好约定 |
| 项目根目录 | ./CLAUDE.md | 提交 | 团队共享的项目核心规则 |
| 本地覆盖 | ./CLAUDE.local.md | 自动 ignore | 个人的覆盖或调试配置 |
| 父目录 | 从 cwd 向上查找到 / | 不推荐 | Monorepo 场景下根目录与子包同时生效 |
| 子目录 | ./subdir/CLAUDE.md | 按需 | 当 Claude 访问该子目录文件时才加载 |
所谓 Monorepo，就是单个代码仓库包含多个独立项目，比如一个仓库里有 frontend/、backend/、shared/。在这种结构下，向上查找机制可以让根目录的规则对所有子包生效，而每个子包又可以有自己的补充规则。
还有一个细节值得注意：子目录的 CLAUDE.md 是按需加载 的。只有当 Claude 实际读取某个子目录下的文件时，才会加载该目录中的 CLAUDE.md。这个设计挺聪明，省 Token。
如果你面对的是一个已有项目，不想从零写起，可以在项目根目录运行 /init（进入 Claude 会话后输入即可）。Claude 会自动扫描你的代码库，然后生成一份初始 CLAUDE.md，通常包含：
不过，自动生成的东西难免有不准确的地方。生成之后一定要手动编辑，删掉猜错的，补上遗漏的。/init 给你的是毛坯房，精装修得自己来。
如果已经有一份 CLAUDE.md 想重新生成，可以用 /init --force 覆盖现有版本。
首先是硬约束：保持 200 行以内 。太长了 Claude 会忽略尾部内容，这不是偷懒，是注意力机制的问题，就像你给大厨贴了一百条纸条，他大概率只记得前二十条。
其次是内容选择：只放对工作流有持续影响 的信息。API 文档、教程之类的参考材料不要放进去，那是在浪费每一条都会被读到的宝贵行数。
最后是结构：用清晰的 Markdown 标题分层。
一个 Python 项目的 CLAUDE.md 大概长这样：
1 | # Project: FastAPI Backend |
虽然模板看着整齐，但实际写的时候不必追求面面俱到，后边使用 Claude 中最常出错的环节，才是最值得写进备注的。如果你发现自己反复纠正 Claude 同一个问题，那这个问题就该进 CLAUDE.md 了。
当项目规模增长，CLAUDE.md 变得臃肿，200 行装不下怎么办？可以把规则拆分到 .claude/rules/ 目录下。
这个目录下可以放多个 Markdown 文件，分为两种：
普通规则文件 （没有 path: 字段）：会话启动时加载，效果等同于写在 CLAUDE.md 里。
路径限定规则文件 （包含 path: YAML 字段）：只有当 Claude 读取匹配路径的文件时才加载。这是省 Token 的大杀器，前端规则只在读前端代码时才生效，后端规则只在读后端代码时才生效。
比如你可以在 .claude/rules/frontend.md 里这样写：
1 | path: src/frontend/** |
path: 字段和正文之间用 --- 分隔。上面那行声明了这条规则只在 src/frontend/ 目录下生效，下面的正文就是规则本身。简洁，克制，该出场时再出场。
到现在为止，我们一直把 CLAUDE.md 当成纯文本在用，写什么就注入什么。但其实它有几条不算显眼的专属语法，知道了能省不少事。
CLAUDE.md 里可以写 @path/to/file，Claude Code 在加载时会把这个文件的内容展开并注入。就像你在菜谱里夹了一张纸条：”详细步骤见附录 A”，大厨会自动翻到附录 A 去看。
1 | # 项目规范 |
几个要点：路径可以是相对路径（相对于写 @ 的那个文件所在目录），也可以是绝对路径；导入可以嵌套，但最多 5 层，防止无限递归。
一个容易踩的坑：@ 导入并不能省 Token。被导入的文件内容照样会完整注入上下文，所以它解决的是组织问题，不是成本问题。你把 500 行的 API 文档 @ 进来，大厨照样得逐字读完。
如果你在 CLAUDE.md 里写了 HTML 注释，比如 <!-- 这段是给人看的维护笔记 -->，Claude Code 在注入上下文之前会把这些注释剥掉。也就是说，注释里的内容 Claude 永远看不到，也不消耗 Token。
所以，你可以在 CLAUDE.md 里留下为什么这么写的备忘给自己看，而不浪费 Claude 的注意力。不过要注意，注释写在代码块里面是不会被剥掉的，因为代码块里的内容是字面量。
前面已经讲了 path: 字段的基本用法，再补充一个细节：path: 支持多个 glob 模式，用 YAML 列表写法。
1 | --- |
当 Claude 读取匹配这些路径的文件时，这条规则才会被加载。不匹配就不加载，一分 Token 都不多花。
所有这些语法背后，有一个加载顺序值得了解。Claude Code 从当前目录向上遍历，把沿途找到的 CLAUDE.md 全部拼接注入，根目录的在前、工作目录的在后。所以离你最近的那份 CLAUDE.md 是最后被读到的，权重也最高。
同一目录下，CLAUDE.local.md 排在 CLAUDE.md 后面，所以你个人的覆盖配置总是比团队共享的优先。子目录的 CLAUDE.md 是按需加载的，只有 Claude 实际访问了那个目录的文件，才会读取。
还有一个关键细节：使用 /compact 压缩上下文之后，只有项目根目录的 CLAUDE.md 会从磁盘重新读取并重新注入，子目录的不会。所以那些最不能丢的规则，一定要放在根目录的 CLAUDE.md 里。
如果你在 GitHub 上逛过开源项目，可能见过一个叫 AGENTS.md 的文件。它和 CLAUDE.md 长得像、用途像，但不是一个东西。
AGENTS.md 是 GitHub 定义的规范，给 GitHub Copilot 的 Agent 用的；CLAUDE.md 是 Anthropic 定义的规范，给 Claude Code 用的。两家的 Agent 都需要一份”操作规范”，但各自只认自家的文件名。
它们都是放在仓库里的 Markdown 文件，都是给 AI Agent 注入项目上下文和规则的。
AGENTS.md 正在演变成通用的 AI Agent 配置文件标准，不只是 Copilot，Cursor、Codex 等 AI Agent 也开始支持，它也成为 Linux 基金会开始支持的标准。
不过，如果你只用 Claude Code，使用 CLAUDE.md 更值得推荐，它有更强大的专属内置指令。
如果你的团队既用 Claude Code 又用 Copilot，两份规范维护起来会头疼吗？倒也不必。推荐的做法是用 CLAUDE.md 导入 AGENTS.md：
1 | @AGENTS.md |
这样，两份规范共享同一份基础内容（写在 AGENTS.md 里），Claude Code 特有的规则追加在后面。Copilot 只读 AGENTS.md，Claude Code 先读 AGENTS.md 再读追加部分，互不干扰，也不用维护两份重复的规范。
如果你只用 Claude Code，直接写 CLAUDE.md 就好，不必创建 AGENTS.md。反过来，只用 Copilot 的话写 AGENTS.md 即可。只有两边都用的时候，才需要考虑这个桥接方案。
另外，你也可能看到过 CONTEXT.md，project-context.md 一类的工程文件，它们本质上具有相同的功能，只是用于不同的 agent。
希望将来这些大佬们能把这些协议性的东西规范一下，避免大家理解上的差异。
还有一点：运行 /init 时，如果仓库里已经有 AGENTS.md（或者 .cursorrules、.windsurfrules），Claude Code 会读取这些文件，把相关内容整合进生成的 CLAUDE.md。所以即便你忘了手动桥接，/init 也能帮你兜个底。
/context —— 查看当前上下文中已加载的全部 CLAUDE.md 内容。如果怀疑某条规则没生效，先看这个。/init --force —— 重新生成 CLAUDE.md，覆盖现有版本。/cost —— 查看加载 CLAUDE.md 消耗了多少 Token，通常很少，大约 200-500，不用太担心。如果你把项目级 CLAUDE.md 提交到公开仓库，那里面写的所有内容都会被看到。所以，不要在项目级 CLAUDE.md 里放 API Key、内部域名或敏感路径。这类信息应该放在 CLAUDE.local.md 里，并加入 .gitignore 避免泄露。
在根目录放一份通用规则，在每个子包中放自己特定的规则。Claude Code 的向上查找机制会让根目录的规则对所有子包生效，而子包的规则又可以对根目录的规则做补充或覆盖。
可以，Claude 完全理解中文。不过推荐命令和路径用英文，避免编码问题。
Claude Code 会自动转换路径分隔符，这方面不用操心。
CLAUDE.md 这东西，说到底就是一个 Markdown 文件，没什么技术门槛。但正是这种看似简单的机制，解决了一个根本性的问题：如何让一个无状态的 AI 助手保持对项目的持久记忆。
不过，记忆只是第一步。如果你想让大厨不只记住你家不吃香菜，还能按标准流程做出一整套招牌菜，比如”按公司规范做安全审查”或”自动生成周报”，光靠备注可不够。下一篇文章，我们看看怎么用 Skills 给 Claude 教一套完整的烹饪套路。
封面图片来自豆包 AI。
本文同步发布在知乎账号下：Claude-Code-实践指南（二）：编写操作规范
年初，我也搭上了 AI 时代的公交车。刚开始试用时，我的体验是： ”感觉 Claude Code 写出的代码就是一坨啊？AI agent 真的有用吗？”。
后来，又来一次在家做饭的时候突然想明白了——
一个人做饭，从洗菜、切菜、调味到掌勺，全靠自己。如果你家里请了一位米其林大厨，你只需要说”给我做个宫保鸡丁”，大厨自己就能做好了。Claude Code 就是这样一个大厨。
虽然它切菜很快，但它并不知道你的口味偏好，你家的厨房设施，这些还得你说了算。
嗯，我挺满意这个比喻。
这是我计划编写的 Claude Code 实践指南的第一篇文章，我想先简单介绍一些概念和用法。这种新的工作模式是否能提高工作效率暂且不提，了解他是什么，能干什么，依然很重要。
先说 Claude。Claude 是 Anthropic 公司的大语言模型家族，包括 Claude Sonnet、Claude Opus 等等，它是一个”能听懂话的大厨”。
再说 Claude Code。Claude Code 是运行在终端里的 AI 编程助手，是一个 CLI（Command Line Interface，命令行界面）工具。它不光能听懂话，还能读取文件、编辑代码、执行命令、完成多步骤开发任务。相当于给大厨配齐了刀具、灶台和食材仓库的后厨系统，不光能听懂，还能动手。
打个比方：Claude 是那个你正在面试的大厨，你说”酸辣汤怎么做”，它能告诉你配方和步骤；而 Claude Code 是那个已经站在灶台前的大厨，你说”做一碗酸辣汤”，它直接走进厨房，把汤端出来。
除了 Claude Code，目前市面上 AI 编程工具不少，各有各的风格：
| 工具 | 模型 | 所属公司 | 关键特点 | 适合场景 |
|---|---|---|---|---|
| Claude Code | Claude 系列 | Anthropic | 代码专用优化，Agent 自主性高 | 复杂代码库重构、多文件修改 |
| Copilot | GPT / Claude | Microsoft | 补全为主，对话辅助 | 日常编码补全 |
| Cursor | 多类模型 | Cursor | 基于 VS Code，内置 AI 的 IDE | 喜欢独立 IDE 的用户 |
| Zed | 多类模型 | Zed | 极致性能，自研 GPUI，AI 原生集成 | 喜欢 IDE 但接受不了 VS Code 的速度的用户 |
| Codex | o3 / codex-1 | OpenAI | 开源终端编程代理，Agent 自主性高 | 自动化脚本、代码生成与执行 |
| Gemini | Gemini 系列 | 上下文窗口大，多模态能力强 | 大型项目、长上下文分析 | |
| OpenCode | 多类模型 | Anomaly | 代码搜索和理解能力强 | 代码检索、Bug 定位 |
| Windsurf | 多类模型 | Codeium | 注重协作体验，适合团队 | 团队协作、初学者友好 |
简单介绍一下这些新面孔：
Codex 是 OpenAI 推出的开源终端编程代理，基于 o3 和 codex-1 系列模型，定位和 Claude Code 类似，也是一个能直接在终端里读写代码、执行命令的 Agent。
Gemini 是 Google 的多模态大模型，上下文窗口可以做到 1M tokens 以上，理论上可以一次性读完一个中型代码库再分析，适合长上下文分析场景。
OpenCode 来自 Anomaly，是一个开源项目，在行业内非常火，可以接入各大模型商的大模型。
Windsurf 背后是 Codeium，就是那个早年免费替代 Copilot 的 Codeium。Windsurf 强调协作体验，定位更偏向团队使用和初学者。
安装 Claude Code 的前提如下：
操作系统 ：macOS、Linux、Windows WSL2 均可。
前置依赖 ：Node.js 18+ 和 npm。
主安装命令 很简单，一行搞定：
1 | # macOS / Linux / WSL |
Windows 用户用 PowerShell：
1 | irm https://claude.ai/install.ps1 | iex |
如果你更习惯 Homebrew，也可以：
1 | brew install --cask claude-code |
安装完成后，验证一下：
1 | claude --version |
如果能看到版本号输出，说明安装成功。如果提示”command not found”，大概率是 PATH 没配好，试试重新打开终端窗口。
大厨请来了，但干活得开工资。Claude Code 提供多种付费方式。
如果你已经有 Claude Pro、Max 或 Team 订阅，这是最省心的方式。直接在终端运行 claude，会自动打开浏览器要求登录 Anthropic 账号，登录后自动绑定订阅权益，不需要手动管理任何 API Key。
优点是简单，不需要记 Key，费用包含在月费中。缺点是重度使用可能触发速率限制。
如果你没有订阅，或者用量波动大，可以用 API Key 按量付费。步骤如下：
1 | export ANTHROPIC_API_KEY="sk-ant-..." |
测试一下：
1 | claude "用 Python 写一个计算斐波那契数列的函数" |
如果 Claude 正常返回了一段代码，说明认证成功。
费用说明 ：API 方式按 Token 计费。Token 是模型读取文本的最小单位，约等于 0.75 个英文单词或半个中文字（不同模型有差别，感性认识下）。输入和输出分别计价，具体费率以 Anthropic 官网为准。新注册用户通常有试用额度。
什么时候用订阅，什么时候用 API？
如果你是个人用户，主要用于对话、写作或学习，编码的工作比较轻量级，选择订阅制更省心，容易控制预算。当然，前提是你会持续用下去。
如果你的工作涉及大量代码生成、系统自动化、数据处理，或者你将来可能希望更精确地控制成本，使用 API 更合适。
如果你认为 Cluade 太贵，只是想简单用用，其实借用 Claude Code 但不为 Claude 付费也是可以的，国产的模型会便宜一些。
注意封锁
由于 Anthropic 公司的老板对我们比较抵触，所以在大陆地区订阅 Claude 可能（极大可能）会被封号。万一被封了，想开点，因为大家都一样。
如果被封锁，也许可以找付款平台申诉退款，当然也得做好 money 打水漂的心理准备。
封锁的机理其实一直在层层加码，所以我这里不展开讲如何规避了。
在正式开始 cowork 之前，有几个概念值得先理清楚。
词元（Token） ：每次调用的计费单位。在 Claude Code 会话中，你可以用 /cost 命令查看当前会话消耗了多少 Token、花了多少钱。
上下文（Context） ：Claude Code 默认支持 200K tokens 的上下文窗口。Max 及以上订阅可以直接使用 1M 上下文窗口（仅限特定模型），Pro 订阅需要额外付费才能用。这意味着你可以在一次对话中给它相当多的代码和背景信息，它都能记住。
会话（Session） ：从 claude 启动到退出的一次连续对话。在同一个会话中，Claude 会保持对之前交流的记忆（未压缩上下文情况下）。退出后不用担心丢失，下次启动时可以用 claude --continue 恢复最近的会话，或者用 claude --resume 从历史会话中选择一个继续。
在 AI 圈子里，”Agent”这个词被用得太多了，每个人说的还不太一样，所以我们先把这个概念理清楚。
简单说：AI Agent = 会用工具的 AI。
普通的 AI 对话，比如你在网页端用 Claude 或 ChatGPT，你说”帮我写个函数”，它给你一段文字代码，仅此而已。你还得自己复制粘贴到编辑器里，自己跑测试，自己修报错。
而 Agent 模式的 AI，比如 Claude Code，不光能给你代码，还能帮你：
类比一下：普通 AI 就是个只能的对话助手，它可以告诉你详细的菜谱，但需要你自己照着做；Agent 模式的 AI 像是直接走进厨房，帮你把菜做出来。
Claude Code 就是一个 AI Agent。你说”帮我重构 auth 模块”，它会先分析现有代码结构，然后制定重构计划，接着逐个修改相关文件，最后运行测试验证。
整个过程中，它自己做决策，不需要你一步步指挥。当然，它做的决策不一定每次都对，所以最后你还是要验收。
当任务太复杂时，Claude Code 还可以启动 Subagent（子代理）来并行处理多个独立子任务。
比如你让 Claude “同时处理这三个独立功能”，主 Agent 负责任务分解和协调，Subagent A 处理功能一，Subagent B 处理功能二，Subagent C 处理功能三，各自独立工作，完成后结果汇总给主 Agent。
其实 Subagent 是 Claude Code 的核心机制之一。很多时候你不需要主动调用，Claude 会自动根据任务类型启动合适的子代理，比如用 Explore 类型的子代理搜索代码，用 Plan 类型的子代理设计方案。你在不知不觉中就已经用到了。
Tool Use（工具调用） 是 Agent 实现能力的技术基础。简单说，就是给 AI 模型装上”手”，让它可以调用外部接口来完成任务。
Claude Code 中的 Tool Use 包括：
Read / Write / Edit：文件系统操作，相当于大厨的刀和锅Bash：执行 shell 命令，相当于打开灶台的火Grep / Glob：搜索代码内容和文件模式，相当于在食材仓库里找东西WebFetch / WebSearch：获取网页内容和搜索互联网，相当于大厨去隔壁市场采购Agent：启动子代理，相当于叫一个帮厨来搭手这些工具让 Claude 从”能说会道”进化到”能说会做”。没有 Tool Use，大厨只能念菜谱给你听；有了 Tool Use，大厨才能真的走进厨房。
使用这些 Tool 依赖一个叫 MCP（Model Context Protocol，模型上下文协议）的东西，这个东西是 2024 年 Anthropic 开放的一个标准，现在不只有 Claude Code 在用，其他 AI Agent 也同样用。
概念讲完了，让我们动手试一下。
找任意一个项目目录，哪怕是空的也行，然后启动 Claude Code：
1 | cd my-project |
进入交互界面后，输入：
1 | 分析这个项目的目录结构，告诉我主要的模块有哪些 |
Claude 会自动调用 ls、cat 等工具去读取你的项目文件，然后输出分析结果。如果你在一个 Node.js 项目中，它可能会告诉你 src/ 是主代码目录、tests/ 是测试目录、package.json 管理依赖等等。
这个过程中你不需要指定它用什么命令，它自己会判断需要读取哪些文件，就像你不需要告诉大厨用哪把刀切洋葱一样。
在 Claude Code 的交互界面中，斜杠命令是常用的操作入口：
/help：查看所有命令/model：切换 Claude 模型（比如从 Sonnet 切到 Opus）/init：在项目中初始化 CLAUDE.md 配置文件/resume：恢复之前的历史会话/clear：清空当前会话历史（硬重置，会丢失所有上下文）/compact：压缩上下文（保留关键信息但释放 Token，不会完全丢失记忆）/cost：显示当前会话的费用估算/diff：查看当前未提交的代码变更/exit：退出其中 /compact 是个值得记住的命令，当会话变长、Token 消耗开始让人肉疼的时候，用它压缩一下，能省不少钱。Claude Code 自己也会自动压缩上下文。
大厨请进了厨房，也试了第一刀。
不过有一个问题：每次新会话，它都会忘记你家厨房的规矩，比如盐罐放哪、不吃香菜、大火爆炒别太干。下一篇文章，我们会给 Claude 写一份”厨房操作规范”，也就是 CLAUDE.md 配置文件。
封面图片来自豆包 AI，Prompt：构成主义、微观元素、自然景观、拼图艺术。
本文同步发布在知乎账号下：Claude Code 实践指南（一）：开始第一次对话
在日常终端操作中，许多经典命令行工具（如 grep、ls、cd、df 等）已经服务了几十年。它们稳定可靠，但也逐渐暴露出一些性能或用户体验上的不足。近年来，一批新的终端工具陆续出现，它们通过更智能的算法、更友好的交互界面以及更丰富的输出格式，为开发者提供了更高效的命令行体验。
本文介绍几个我在用的现代终端工具，你可以按需要选择是否去试用下，这些工具都是开源的，所以能保证它们的安全可靠。
由于不同操作系统、工具链有差异，我不会列出每个工具的安装方式，请自行到仓库路径下查找。
替换目标 ：grep
核心优势 ：自动遵守 .gitignore 规则，支持并行递归搜索，内置高亮显示，并可搜索压缩文件。
与 grep -r 相比，rg 在大型代码库中的搜索速度通常快数倍至一个数量级。它默认启用正则表达式，并会自动跳过隐藏文件及二进制文件。
常用选项与示例 ：
1 | rg "function_name" # 递归搜索当前目录 |
同名替换？ ❌ 不能rg 并不完全兼容 grep 的所有选项（例如 -P 启用 Perl 兼容正则表达式，或某些输出格式控制选项）。许多现有脚本依赖 grep 的特定返回码或输出格式，直接替换可能导致意外行为。建议将 rg 作为独立工具使用。
仓库位置： https://github.com/BurntSushi/ripgrep
替换目标 ：find
核心优势 ：语法更简洁，默认忽略隐藏文件和 .gitignore 中指定的文件，输出彩色高亮，支持正则表达式。
相比 find 的复杂谓词组合，fd 采用直觉化的参数设计，例如 fd pattern 即可完成递归文件名匹配。
常用选项与示例 ：
1 | fd source # 查找路径下匹配 source 的文件 |
同名替换？ ⚠️ 谨慎，仅限交互式find 的参数体系与 fd 完全不同，且大量自动化脚本依赖 find 的 -exec、-print0 等特性。强行设置 alias find='fd' 会破坏这些脚本。建议将 fd 作为独立工具使用。
仓库位置： https://github.com/sharkdp/fd
替换目标 ：ls 核心优势 ：支持图标显示、树形视图、Git 状态标识，并可按文件扩展名排序。
eza 在输出中包含文件类型图标、每个文件的 Git 修改状态（例如 M 标记），并以不同颜色区分文件类型，显著提升了目录列表的可读性。
原 exa 项目已归档，不再推荐，eza 为其活跃分支。
常用选项与示例 ：
1 | eza -l --git # 显示详细信息及 Git 状态 |
同名替换？ ⚠️ 谨慎，仅限交互式ls 是 POSIX 标准定义的基本命令，许多脚本会解析其输出（例如通过管道获取列信息）。虽然 eza 实现了 ls 的大部分常见选项，但输出格式（如颜色代码、额外的 Git 列）可能破坏脚本逻辑。安全做法是仅在交互式配置中设置 alias ls='eza'，并避免在脚本中使用该别名。
当然，更安全的做法依然是以独立工具使用。eza 对小拇指不友好，可以设置额外的一些别名：
1 | if command -v eza &> /dev/null; then |
仓库位置： https://github.com/eza-community/eza
替换目标 ：diff
核心优势 ：解析源代码的抽象语法树（AST），从结构层面展示差异，而非逐行比较。
difftastic 能够识别括号匹配、缩进变化等结构性修改，避免了传统 diff 因格式化变动而产生的大量无效差异。支持多种编程语言，输出带有侧边栏和可折叠区域的界面。
常用选项与示例 ：
1 | difft left.c right.c # 对比两个文件 |
它同样可以用于 git diff，效果很显著。由于它懂语法，所以在展示代码修改差异时，可读性更强。
1 | git config --global diff.external "difft --syntax-highlight off" |
有个缺点是，它需要分析语法树，所以在性能方面，比原生 diff 要慢，在打开大文件时会比较明显有延迟。
同名替换？ ⚠️ 谨慎，仅限交互式diff 的退出码和输出格式被广泛用于自动化流程（例如 patch 工具、CI 脚本），而 difftastic 专为人工审阅设计，不具备兼容性。建议将 difft 作为独立工具使用。
仓库位置： https://github.com/Wilfred/difftastic
替换目标 ：cd 核心优势 ：基于频率和最近使用时间记录访问过的目录，支持模糊匹配快速跳转。
使用 z 命令后跟部分目录名，即可直接跳转到匹配的目标目录，无需输入完整路径。zoxide 会维护一个本地数据库，自动更新访问权重。
常用选项与示例 ：
1 | z src # 跳转到包含 "src" 的最常用目录 |
如果配合 fzf，可以实现打开交互式窗口来选择性跳转，也挺有意思的，不过我不怎么用。fzf 是一个高性能的模糊匹配工具，也很不错，但它不属于可替换原生终端程序的范畴，我便没有列在本文中。
同名替换？ ❌ 尽量不要 cd 是 shell 内建命令，直接影响当前 shell 的进程工作目录。zoxide 虽然可以与 cd 配合使用，但无法完全模拟 cd -（返回上一目录）或 cd "$VAR" 等行为。建议将 z 作为独立工具使用。
仓库位置： https://github.com/ajeetdsouza/zoxide
替换目标 ：top
核心优势 ：彩色界面、鼠标支持、树状进程视图、可直接发送信号，并显示每个 CPU 核心的使用率。
htop 允许用户使用上下键滚动进程列表，按 F9 快速终止进程，按 F5 切换树状视图，比 top 的默认交互更为直观。
常用选项与示例 ：
1 | htop # 启动交互式监控 |
同名替换？ ⚠️ 仅限交互式，不适合脚本top 的批处理模式（-b）常被脚本用于采集系统信息，而 htop 不支持该模式。因此可以在交互环境中设置 alias top='htop'，但不应在 .bashrc 等全局配置中覆盖，以免影响自动化任务。
仓库位置： https://github.com/htop-dev/htop
替换目标 ：wget / curl（下载文件场景）
核心优势 ：通过多个连接分段下载同一文件，可显著提升下载速度（尤其在网络延迟较高或服务端限速时）。
axel 会将目标文件切分为多个部分并行获取，最后自动合并。它支持断点续传和限速功能。
常用选项与示例 ：
1 | axel -n 10 -o ./file.zip "https://example.com/bigfile.zip" # 10 线程下载 |
同名替换？ ❌ 完全不能wget 和 curl 拥有极其丰富的参数体系（HTTP 头、Cookie、POST 数据等），axel 仅覆盖最简单的下载场景。不应尝试替换，而是将其作为补充工具使用。
仓库位置： https://github.com/axel-download-accelerator/axel
替换目标 ：cat
核心优势 ：自动识别文件类型并添加语法高亮，集成 Git 行级修改标记，默认使用分页器（less）避免刷屏。
bat 在显示代码文件时，会在行号旁标注 Git 的增删状态，并提供与 IDE 类似的色彩方案。
常用选项与示例 ：
1 | bat main.rs # 高亮显示 Rust 代码 |
同名替换？ ⚠️ 部分可行，但有风险
当 bat 的输出被重定向到管道时，它会自动关闭分页和高亮，行为接近 cat。但它仍可能输出额外的元信息（如默认的文件头）。需要谨慎考虑是否替换。
仓库位置： https://github.com/sharkdp/bat
替换目标 ：man（仅限快速查阅常用用法）
核心优势 ：提供社区维护的常见命令示例，每个命令通常包含 4–6 个典型场景，避免翻阅冗长的手册页。根据系统语言还能自动显示不同的翻译版本（比如中文）。
tldr 适合快速回忆参数格式，例如 tldr tar 会直接显示压缩和解压的常用命令。每个工具的示例描述都是网友手工维护的，如果没有你想要的工具，也可以到仓库去提交。
常用选项与示例 ：
1 | tldr tar # 显示 tar 命令的常见示例 |
同名替换？ ❌ 完全不能man 提供完整的结构化文档及 man -k 关键词搜索功能，tldr 无法覆盖这些用途，它们的选项也完全不同。两者属于是同一功能的不同实现。简单查询可以用 tldr，如果想完整了解一个工具，依然得打开 man。
仓库位置： https://github.com/tldr-pages/tldr
一个 Rust 实现的客户端： https://github.com/dbrgn/tealdeer
替换目标 ：du
核心优势 ：更实用的展示路径下各文件和目录的磁盘使用量。它是并发统计的，所以性能更好，显示也更人性化。
常用选项与示例 ：
1 | dua # 统计当前路径下的磁盘使用量 |
同名替换？ ❌ 完全不能du 的输出经常被脚本解析（例如 du -k | cut -f1），两者是完全不同的交互实现。请将 dua 作为独立的分析工具使用。
仓库位置： https://github.com/Byron/dua-cli
替换目标 ：df
核心优势 ：使用进度条和颜色区分不同设备类型（本地磁盘、挂载点、临时文件系统），支持 JSON 输出。
duf 会自动分组显示设备，并用绿色到红色的渐变表示使用率，便于快速识别磁盘占用过高的分区。
常用选项与示例 ：
1 | duf # 显示所有挂载点 |
同名替换？ ❌ 完全不能df 的 POSIX 兼容输出格式（-P 选项）被许多运维脚本依赖，而 duf 的输出结构与之不同，所以不要同名替代 df。请直接使用 duf 作为磁盘统计工具使用。
仓库位置： https://github.com/muesli/duf
上述工具在特定场景下显著提升了终端操作效率，但它们并非完全兼容 POSIX 标准命令。因此在实际使用中，建议采取以下策略：
alias 指向这些现代工具，享受更丰富的功能和更好的用户体验。/bin/grep、/bin/find），或通过绝对路径调用，以确保可移植性和可预测的行为。命令行世界没有“终极”工具，只有不断适应需求演进的实用方案。合理利用这些现代终端工具，可以在不牺牲可靠性的前提下，大幅提升日常开发与运维的舒适度。
本文同步发布在知乎账号下：汇总几个终端小工具
标题图片使用豆包 AI 生成，提示词：终端窗口、黑色背景、涂色画板、毛笔、16:9 画幅。
我出生在一个普通的工薪家庭。我父母为我赐名 “杨柳”，据他们后来给我的解释，并未对这个名字有什么特别的深意。不过，它一直携带着一个有趣的故事，让母亲反复提及。
我有个堂哥，叫杨树。我出生时，父亲向我爷爷奶奶请求赐名，爷爷奶奶是农民，没有什么文化，奶奶说，既然有个哥哥叫杨树，不如就叫 “杨二树” 吧。现在看起来滑稽的命名，在当时的农村，其实非常普遍，用数字来表明辈次关系，类似于古代的 “伯、仲、叔、季”，使用 “大、二、三、四” 更加口语化也更容易理解。
妈妈家比爸爸家有文化些，我姥爷是中学教师，妈妈委婉地说，不如叫 “杨柳” 吧，杨柳青青，富有生命力。在我看来，虽然 “杨柳” 并不是我很满意的一个名字，但总比 “二树” 要强很多了。
基于我的大名，我的乳名也就出现了 “柳柳”，“柳子”，“柳毛”，以及姥姥专用的 “臭毛”。
古人说，名者，命也。名字在出生时由长辈赋予，寄托着最初的期待，但也确实客观上塑造了我后天的性格和行为。
杨柳，是一个很美的词，杨树正直、柳树柔韧，杨柳代表着生命力，也代表着豪迈和通达。父母没有在我的名字中留下对我生命宏大的期许和祝福，反而做出了留白，似乎有意为我的创作留下空间。
杨属于我的姓，所以很多时候，人们会直接评价你的名，“柳” 虽然中性，但在中国文化中更多指妖娆和婉约，也就多指代女性。在我性启蒙的那个年龄段，我盲目地对这个事儿特别固执，认为我一个男孩不应该拥有一个 “女名”。
在古代，行成人礼时，会为孩子赋予一个 “字”，之后，这个孩子就成为了 “人”。字是对名的补充和深化，赋字，也是自己在这十几年中，通过自己的学识和自我了解，重新对自己下定义的一个机会。
现在社会已经没有 “字” 这一说了，名和字合并成名字，成为人一生中的代词。不过，我想到了改名。我幼小时，性格内向，不善言谈，不喜外出，在我看来，这就是女孩才会有的习惯。在那个懵懂的、充满性别偏见的时代，我幼稚地把这一切归结为，我起了一个 “女名”。
我认为，姓名就像生命一样，是父母赋予的，妄不可随意弃置。但又考虑确实想改名，最终决定，在现有的 “杨柳” 后边，加一个字，作为我自己赠给自己的字，作为我对自己人生底色的期许。
我和父母讨论过，他们给了我一个建议，不如加一个 ming 音字。我表示同意，爸爸给的建议是 “杨柳明”，指柳暗花明之意，但我不想捧一贬一，我的 “柳” 字应该有更多的解释；妈妈给的建议是 “杨柳鸣”，指一鸣惊人之意，亦指树木也能说话的奇观，但我认为，鸟入树林而鸣叫，不那么酷。
我用了一下午的时间，翻遍了字典，最后决定用 “铭”。在我看来，我的 “柳” 代表了柔韧和变通，应该再加一个 “坚硬” 的词进来。“铭” 字指刻在器物上的文字，用于警醒自己，比如 “座右铭”，刻在石头金属上，也不容易磨灭，有青史留名之意。
古人在赋字时，有些会和名前后呼应，比如诸葛亮字孔明，有些会和名互为补充，比如孔丘字仲尼。“铭” 既能表名词，也能表动词，表动词时，可以指 “刻在石头上”。杨柳是自然所为，是一种被动接受，而“铭”是人工所刻，是一种主观行为。在这份天性之上，我想要靠自己刻出自己独特的人生。
数字时代，人出现了新的代词。在网络生活中，为了能保护隐私，往往会起网名。网名总是天马行空，它代表着信息时代的新人类，好奇、兴奋，和对新时代的美好向往。网名就像是古人的 “号”，号是文人自取，任意发挥，表达志趣的代称，比如苏轼的 “东坡居士”。
我最初的网名，是在第一次接触互联网时，在创建 QQ 账号时起的，叫 “迁徙的森林”。这个有趣的名字，有这么个由来，我的大名中有 “杨柳” 二字，自然我希望在网名中也保有 “树” 相关的寓意。再加上那段时间比较沉迷魔兽争霸，对里边的精灵一族很向往，精灵族有很多可以移动的古树，看起来真的很酷。
另外，它其实也饱含着另一层意思。
我不但名字里带有 “树”，我的童年也实实在在的和树相关。我出生时，我姥爷就承包着当地的一大块果园，据说是妈妈还小的时候，就开始承包的。果园里大多数是酸果子（一种沙果），还有苹果、梨、少量的桃和杏，还有海红子（类似樱桃）。说我的课余生活，是在果园里长大的，一点也不为过。关于果子、鸟、蛇和蚊子，我都可以单独写一篇文，恰可仿着鲁迅的《从百草园到三味书屋》。
然而，美好的记忆终将随着时间化成沙子。
我上初中后，这片果园消失了。姥爷承包的果园是属于学校的，但学校倒闭了。果园作为学校资产被用来清算，最终全部砍伐，改为耕地。曾经，从院子里望去，满眼地绿树茵茵，现在，只看到远处起伏地沙丘。
这就是我第一个网名中，另一层意思。在大人眼里边，果园是一份资产，是一份契约，在我眼里边，是承载我童年生活的襁褓。
我的第二个网名，是在高中时改的，叫 “西伯利亚雪人”。高中时没有太多时间上网，那段时间也阅读了很多文学著作，对充满白雪皑皑的邻国北疆特别仰慕。我的生日是在冬天，我也很喜欢冬天下雪，于是，就换了这么个名字。后来直到大学，我的网名都围绕着这个名字转悠，比如 “SiberiaBear”。
父亲通讯录中对我的备注，就是 “雪人”，也来自于这个网名。不过我很不确定，它会不会还有另外一层意思？长大的孩子，犹如冬天的雪人，年前出现，年后消失。
工作后，才后知后觉地意识到，网名和名字一样，也是一个很重要的代称，它是一个人数字时代的标记。运营自己的社交账号和网络动态，就像是培养一个全新的自己，也非常重要。
我重新审视了自己的网名，最后，拟定了一个颇具调侃意味的名字，P2Tree。还记得，曾经奶奶为我赋予第一个名字，但最后没有使用，现在，那就重新用起来吧。2Tree 便指 “二树”。二树，就像二狗子，二哈喇子，二流子一样，用在真名上太过于粗陋，但网络极大的包容性，开放性，却恰好合适。
P 这个开头，来自于杨树的英语 Populus，间接地，我依然把我的姓氏，放在了网名中。我爱人也这么做了，不过，她是以音转形，我是以英转形。当然，另一个必须要加一个字母到前边的理由是，我的职业病。程序中定义一个符号名字，规则不允许以数字开头，加个字母，看起来更舒服。
2 除了 “二树” 中的 “二” 一义外，也有英语 “to” 之意，类比于 P2P，代表着一种连接，一种将传统姓氏和网络生活的连接，一种将宗族印记和情感经历的连接。
二十一世纪的 “名与字”，已经不局限于传统和礼教的产物，而成为一种自我构建的痕迹。“杨柳铭” 和 “P2Tree” 分别同为三个音节，称起来朗朗上口，又存在着一种独特和隐晦的关联。
直到我的 30 岁后，我才意识到，我无意中走出了一条和古人命名神似的路，只是用了这个时代的语言，用了我独特的故事。
]]>在知乎闲逛时，发现了一个很有价值的老问题：数学究竟是自然界本就存在的某种联系，还是我们人类的创造？。
这么好的问题，居然4年后我才看到。题主现在应该已经上大学了，估计也有了自己的答案，但我还是忍不住想试着参与下回答，就姑且帮我自己整理下思路吧。
乘法源于人们求土地面积的经验，那么，为什么这种丈量土地的经验能够运用在包括行星轨道在内的那么多领域？丈量土地与行星公转间存在着某种联系吗？宇宙间其它的文明认为这两者之间存在着规律吗？
一个最基本的观点是，这个世界的信息，本身是混沌的，人类需要用自己的大脑来理解世界，那么必然需要建立一种语言，来描述这复杂的世界信息，形式化的描述有利于思考，也有利于交流。
所以，这个角度来说，数学是地球人创造的一种宇宙语言。
人类在日常生活中，很多问题可以通过这种语言来简化和抽象，进而发现，经过抽象后的数学，可以套用到不同的应用场景，比如丈量土地和计算行星轨道。
丈量土地和行星公转之间没有直接联系，但它们却拥有相同的数学基础，能用我们的数学语言来描述。如果是外星文明，它们的数学语法可能不同，但一定拥有相同的数学原理。其实也不用去地球之外，在我们自己的世界没有完全揭露前，不同大陆的文明，使用的数学就是不同的。
做个有趣的假设，如果外星文明是一种深海文明，它们不是生活在行星的地表，而是生活在大洋的深处。那么，它们没有视力，却有极强的听力，这种单纯使用听力在三维空间中演化的生物，它们的数学和我们将完全不同。比如，它们的数值单位可能是球壳体积，而不是二维值。
不过不管它们的数学是什么形态，当进入宇宙时，它们也会用自己的数学体系，来计算行星运行轨迹（看样子这种生物可能更容易理解三维宇宙的概念）。
数学形式反映事物的本质吗？ 库仑力和外有引力都合乎平方反比律，具有同一数学形式。那么，库仑力和万有引力具有某种共同本质吗？
它们当然具有共同的本质。库仑力和万有引力刚好是微观和宏观两个领域有代表性的概念，它们反应着相同的性质，都是在三维各向同性空间中，传递粒子（引力子或光子）在静止质量为零时的相互作用。它们的数学形态是一致的。
脑洞大开一下，宇宙是否可能在更高维度上，是一个三维的回环。那么三维的极小，可能就连接着极大。此时能用同一种数学形式描述，也就合乎情理了。
科学界的观点是，数学反映了事物的本质。现代科学都在追求一个伟大的梦想，也就是大一统理论。我们想用一套数学语言来描述这个世界上所有的现象。
虽然近现代科学中，提出的一些假设和猜想，至今仍然没有被证明，但人们还是相信，这是人类科学能力的局限，而不是数学的局限。
反过来说，如果有一个现象，和现在的数学理论相悖，那么整个人类文明都将崩塌。不过大可放心，就像曾经发明复数、无理数一样，人类一定可以为数学大厦添砖加瓦，来解释更多的宇宙本质。
冷热、快慢、多少，人们为什么能把这些不同的联系归为一类？因果、并列等逻辑关系，是宇宙真理的一部分，还是我们人类思维的一部分？
首先，这关乎人类如何建立“概念”，这是人类思维的基础。
冷热、快慢这些概念，都是人类创造的，它们用来描述人类感知到的一类客观体验。为了能描述两个不同事物的相对性，人们最初有了 “比…更…”这种描述，但为了能更细分不同体验的相对性，就发明了这些概念。
这些概念用于描述我们客观感受到的宇宙规律，也反应出了我们的思维状态。
因果，并列这种概念，既是宇宙真理，也是人类思维的体现。
当它被看作是宇宙真理时，它是一种逻辑论，也就是说，即便没有人类，甚至没有地球，宇宙运行还是具有逻辑。可能没有我们熟悉的数学，但逻辑本身是存在的。
当它被看作是人类思维时，它是一种工具论，我们创造了这些数学概念，来解释我们感知到的世界运行行为。此时，逻辑是我们叙述和分析世界的工具。
这个问题很有深度，它从数学出发，实则是一个哲学问题。数学只是它的表层语言。
许多动物的脑不能认识到某种联系。如果我们人类无法分辨差异，我们还会提出不等式的概念吗？会不会存在某种我们的大脑无法处理识别的逻辑关系，导致我们的数学不够完善？
这个问题已经超出了数学，进入了认知科学的领域。
如果我们无法分辨差异，我们确实不会提出不等式的概念。
就像我们无法看到四维空间，所以我们也就没有提出在四维空间中能够适用的那些数学概念。或者，如果有一种生活在计算机中的生命，它们演化过程中看到的环境变化，只有 0 和 1 的跳变（他们的数学符号可能是 . 和 ,），那么，在它们从计算机里出来前，就无法创造大于和小于这种逻辑关系。
就像前边说的，我们的数学是我们地球人发明的，用来描述世界的一种形式化语言，如果我们感知不到某些概念，自然也就不会对应创造那些概念的符号。
因为我们的大脑无法处理一些信息，所以，我们创造的数学一定是不完善的。也就是说，我们认识的世界是有限的。
这就是科学发展的动力，用我们有限的大脑，去探索和解释看起来无限的宇宙。我们的数学，实际上已经扩展到远大于我们能理解的世界，何况，我们还能创造概念。
宇宙应该遵循同一的运动法则，但**为什么”more is different”**，复杂系统的运动规律与其部分几乎全然不同？这是宇宙的某种特质还是我们的错觉呢？
很有意思的一个问题。简单元素组成复杂系统时，复杂系统的规律和行为，确实和简单系统不相同。但这不违背事物的基本规律。
简单来说，在组成物质时，新的产物所拥有的物理状态，不只依赖于组成其的基础物质，还依赖于这些基础物质之间的关系。
就像是两个没有关系的陌生人，他们恰好出现在同一个电梯里，大概率什么也不会发生。但如果他们之间认识，那出现在同一个电梯里，大概率就会产生新的信息（简单对话或思维推演）。这种差异就是因为事物之间的关系。
小到基本粒子，大到行星之间，都可能产生关系，产生关系的初始条件和边界条件各不相同。
说的浪漫一些，宇宙的神奇之处就在于，它有基本的运行规则，比如数学和物理，但它也可能将这些基本规则不断组合，产生出新的未知的东西。比如生命、文明和思想。
“直觉”是相对的吗？ 如果有外星人在高速飞行的星系，它们会不会先发现相对论再发现牛顿力学？
你说的“直觉”可能是指我们人类所处的环境和历史经验的总结。显然，“直觉”就是相对的。
我们的文明和科学发展，依赖于它一定是建立在解释这个“观察”的世界为前提的。
如果有一种外星文明，他们星球的时间流速非常快，比如说行星自转速度是光速的一半，也许行星围绕着一个黑洞运转。
显而易见，他们不会觉得自己“快”，因为“快慢”是相对的，在他们的参照体系下，他们的时间是正常的，而当他们开始探索宇宙时，才会发现宇宙中很多区域的时间很慢，也许会得出“时间流速太慢，以至于无法诞生生命”这种观点。
在已知的宇宙学中，光速是恒定的，所以我们才能清晰地假设这个问题。我们所生活的世界，让我们先发现了经典力学，之后才探索了相对论、量子力学这些我们平常观察不到的领域。
而对于外星文明，如果他们的时间流速是稳定的，那么他们也会先发现经典力学，因为早期文明不可能创造大尺度的时间差异。当然，如果他们的星球足够大，比如是一种有着极厚大气的行星，他们作为一种飞行生物，可以快速飞行穿梭，也许他们能够更容易推演出相对论。
发现物理规律，实际上就是找到一个数学公式，满足我们的实验数据。那么，我们可不可以通过计算机给出海量的数学公式，再把实验数据代入，以发现物理规律？
理论上可行，这是人工智能领域的一个研究课题，它有个专门的名字：符号回归。
具体的步骤和你说的相似，先生成很多随机的数学公式，再代入实验数据，选择最优的公式。
然而，这种实验目前还存在困难。
首先，为了结果能足够精确，就需要穷举非常大数量级的输入，放在现在的计算机上，也依然是个非常耗费资源的过程。
其次，机器学习中存在过拟合、局部最优这些概念，计算机也许能给你一个新的、陌生的答案，但科学家经过重复验证，会发现结果并不总是可靠。如果不能通过正向的推导和验证，这样的答案得不到信服。
然后还有最大的一个问题，很多理论依赖于前序理论的出现，也就是说科学演进得一步步走。如果想发现万有引力定律，必须先发现重力、质量等概念。通过计算机发现的新公式，如果没有足够的先验信息，那这种公式是没有意义的。
我对 AI 能参与科学研究这个应用，还是比较保守。当然这个就得看接下来几十年人工智能的发展成果了。
最后，对那个提出问题的网友一些主观评价。
请允许我对你表达敬意，你年纪轻轻就能跳出基础教育的“解题”框架，去思考“知识”的本质，这种习惯难能可贵。你让我再次看到那个年轻时的我。
想想看，好像高中时，如果对学习游刃有余，似乎脑子里就会忍不住蹦出这些看似奇奇怪怪的问题，很可惜我当时没有网络，也没有前辈能交流。记得我当时学椭圆公式时，试着猜想三维椭球的球面公式，但老师说我超纲了（/苦笑）。
你拥有珍贵的元认知能力，也就是说，大多数人只是在学习知识，而你在思考知识的由来和去向。用前几年的网络流行语，便是“你预判了别人的预判”。
我希望未来的年轻人，都能早早有这种能力。它体现出多个不同的特质：
知识可能过时，但这种思考问题的源动力，不会过时，它比任何知识都更可贵。
原文来自 知乎。
]]>告诉你的孩子，十八岁前，不会让他们因为钱而感到窘迫，这是为了塑造自信的性格，但十八岁后，会让他们因为钱而感到烦恼，这是为了培养独立的金钱观。
封面图片是由豆包 AI 生成的图片，一只望向星空的小狗。
转载自我自己的微信公众号，欢迎关注。
前段时间，公司内有过一次关于未定义行为的讨论，我认为很有价值，也从中学到了东西，整理成文。
我简单介绍下几个相关的概念，并着重探讨一些未定义行为的程序用法。
未定义行为，Undefined Behavior（UB），并不是一个软件工程行业专有的话题，而是在各个领域都存在的普遍概念。
比如，开挖掘机可以挖沙子，也可以用来捞鱼，甚至，用它来挖鼻孔也可以，只要驾驶员有足够的能力驾驭它。而挖掘机说明书中，大概率不会提到用它捞鱼或挖鼻孔，虽然理论上有操作的可能性。
这些行为就可以称为使用挖掘机的未定义行为，又或者用手机捣蒜、用验尿机验茶水，都是 UB 行为。
未定义行为发生时，无法预测也无法保证它会产生什么后果，但一定是不推荐的行为。在软件上，通常指可以通过编译的编程用法，但不保证它实际会产生什么运行期效果。
程序存在未定义行为，就意味着它的执行结果有可能正确，也有可能错误，它可能会导致程序崩溃，但也可能看起来一切正常。而决定最终结果的因素，可能是编译器、操作系统、处理器或者运行时物理环境等。
不过需要明确的一点是，未定义行为应当被认为是一种 Bug。虽然很多系统编程中（尤其是使用 ASM、C 和 C++ 编程），程序员会主动利用未定义行为来达到一些目的，但这依然应该被认为是 “利用 Bug 实现特性” 的行为。
对于编译器来说，它永远假设程序中没有未定义行为。换句话说，编译器的编译行为，并不会考虑或处理未定义行为程序的输入。如果程序员意外写出了未定义行为，那编译器可能会忽略，也可能会因此生成错误的目标代码。
一个看似现在运行良好的程序，如果它带有未定义行为，很可能在将来更新编译器版本、或迁移运行平台、或升级其中某个依赖库时，将未定义行为的隐患激活。所以才说，它依然是一种 Bug。
一个注重安全的软件，应该避免出现未定义行为。
除了未定义行为，还有几个类似的名词，有些人可能会搞混。
程序不一定正确或错误，无法预测，但有潜在隐患。
编译器默认忽略并假设输入不含未定义行为。
比如说，内存越界访问是一种未定义行为，它可能不会异常，也可能某次运行时出现奇怪的现象。
同一个程序，不同编译器的实现不固定。或者说，一种实现可能有多种不同的行为，这些行为都是符合标准的。
编译器会选择其中某一种实现来处理未指定行为。
如果程序员忽略了未指定行为，却写出了触发它的代码，那可能会带来意外的结果。
比如说，C++ 中函数参数的求值顺序是一种未指定行为，所以如果代码行为依赖参数求值顺序，可能出现不符合设计的结果。
不常被提到。和未指定行为类似，不同编译器的实现可能不同，但区别在于，它不是标准定义的。
对于这种编译器自行决定的编译行为差异，编译器需要给出使用说明。
C++ 中，明确允许编译器实现自行决定如何操作的一些行为，而不强制统一，比如说，char 是有符号还是无符号，整形数据溢出时的行为等。
这么做是允许编译器针对不同硬件架构做优化，以及兼容历史遗留代码。和未定义行为的区别是，它和未指定行为，不被认为是 Bug，而是编程语言的一部分，由语言标准或编译器说明来规范。
本文先讨论未定义行为。
在 C++ 中，无符号整数溢出不是未定义行为，它的溢出行为由编译器自行决定；但有符号整数溢出，是未定义行为。
比如：
1 | int32_t val = INT_MAX + 1; |
注释中是实际运行（Linux 5.15 64-bit， gcc 11) 打印的结果。
看起来，这个执行结果是正确的，有符号从最大值溢出 1 后，得到了最小值。但这依然是未定义行为。
因为从数学上，有符号的整数溢出是没有被准确定义的，它可以是自然环绕（如上例），也可以是饱和、抛出错误或 0。
这可能带来意外的编译器优化，比如：
1 | for (int i = 0; i <= INT_MAX; i++) { |
编译器可能认为 i 永远不会达到比 INT_MAX 更大的数，从而认为循环体永远会执行下去。所以我们建议，这种代码中，将 i 的类型改为 unsigned int 等无符号数。
虽然在标准中，有符号整型溢出是未定义行为，不过大多数编译器，在未开启激进优化时，会选择用自然环绕实现溢出。
如果不想刻意处理有符号数溢出的行为，使用数学库的 API 是一个推荐的实践。
类似的，整数位移溢出可以看作是对整数乘 2 或除 2 的结果溢出。它也是未定义行为。
访问一个未赋初值的内存处的数据，是未定义行为，这个显而易见。
不过，有一个 C++ 初始化内存的坑，容易踩到这个 UB：
1 | struct Custom { int val; }; |
类型 Custom 只有一个 POD 成员，没有其他任何成员函数和复杂的成员。对于第二个对象 obj2，构造后的 val 值不会被初始化，而对于 obj1，val 值会被初始化为 0。
对于只带有 POD 成员的类型，使用不带括号的 new 关键字创建的对象，其成员不会被默认初始化，从而访问时可能导致未定义行为。
这个概念（Strict Aliasing），是一个 C++ 标准中的规则，它规定了哪些类型的指针可以合法的指向某个内存位置，而不会导致未定义行为。
编译器实现中有一个过程叫别名分析，它的一个作用就是对这些指针类型所指向的实际数据做分析，从而方便后续的优化和变换。多个不同的指针可能指向同一个内存位置，但意外的使用也可能导致未定义行为。
常见的合法别名用法有：
1 | // access member |
也有一些是未定义行为，比如：
1 | int i = 42; |
编译器不会假设 fptr 和 i 有什么直接关系，很可能会产生非预期的结果。
比如说：
1 | void transform(int* arr, float* output, size_t n) { |
当发生激进优化时，可能做向量化处理或整体预取指令，导致最终结果错误。
先介绍下这个概念（One Definition Rule）。C++ 中明确约定，对于一个符号，必须有唯一的一个定义。
如果同一个编译单元中，有多个同名的定义，那么编译会报错。
如果不同编译单元中，有多个同名的定义，那么链接时会报告符号重复定义。
这些都可以由编译器检查出来，但有一个例外。对于模板函数，C++ 允许同名模板函数，有多份定义。
编译器处理这种情况的思路是，在编译阶段，对由模板函数生成的符号增加 .weak 标记，也就是弱符号。在链接阶段，对于同名的弱符号，随机选择一个（通常是第一个遇到的），保留到目标文件，而不会报错。
如果多个定义的模板同名函数，他们的实现是一样的，那不会有什么问题，但如果不一样，则大概率遇到意外情况。比如：
1 | // file1.cpp |
这个例子中，当使用 -O0 编译时，打印出两个 2 或两个 10，但我们预期的是一个 2 和一个 10。而使用 -O2 编译时，能打印出一个 2 和一个 10。
这是因为，当开启优化时，编译器会对简单的函数做内联操作，从而在编译阶段，就消除了符号 process，自然能得到正确的结果。不开启优化时，链接时会仅保留其中一个 process 的实现。
并发编程中有很多未定义行为，其中，对程序重排序可能带来未定义行为：
1 | int x = 0, y = 0; |
编译器可能假设，当 y 为 2 时，x 一定是 1，从而对 observer 中的代码做激进的优化。
然而，在没有一致性同步操作时，这个假设可能是错的。x = 1 和 y = 2 在编译器调度或硬件指令重排序时，完全可以交换顺序。
原因是为了追求兼容性、灵活性和高性能实现。
以 C++ 为例。C++ 的核心目标是零成本抽象，是运行性能最优，它为了达到这个目标，选择信任程序员。从而，编译器也会信任程序员，无论程序员是意外使用了未定义行为，还是故意使用未定义行为来达到某些目的。
这些目的包括但不限于：
未定义行为就像是一种行规，一种默认的使用约定。“用户应当知道这些行为且明白它可能带来的后果”。
不同于 C++，Rust 在设计之初，就确定它的核心目标是系统安全。所以 Rust 语言和编译器能够从语言层面避免不安全的编码。
然而，Rust 这种设计也就限制了语言操作底层硬件和系统的灵活性，所以它不得不额外支持 unsafe 语法，允许在一定程度上允许出现未定义行为。
从而，我们可以换个视角，通过 Rust 的 unsafe 语法规则，来窥探可能存在的未定义行为。
在 unsafe 代码块中，Rust 允许以下 5 类不安全用法（它并未完全禁用安全检查，只是放宽限制）：
unsafe 中，不关心裸指针是否为空、悬垂、未对齐或指向非法内存，这是很多未定义行为产生的根源Send 和 Sync 的特征，跨线程可能带来数据安全问题另外还有一些没有直接对应到规则的未定义行为被释放：
比如，内存模型违规：
1 | unsafe { |
其中 Ordering::Relaxed 可能导致多个不同线程看到的 flag 状态不同。
千万不要小看了每一个未定义行为，我上边列举的几个包括示例代码，都是简化后的结果。实际上，在工程实践中，这样的未定义行为藏在非常隐蔽的地方，调试排查很困难。
最好的策略就是始终保持对它的敏感性，并避免程序中出现任何未定义行为。
本文同步发布在知乎账号下：编译器视角下的未定义行为
最近网上讨论 ChatGPT 的风潮特别旺盛，其中一个热点话题是 chatgpt 的答案准确性，说看似回答的有理有据，实际上可能其训练数据并不准确，从而导致它的回答是不准确的。这个观点我认同，但我还认为没必要只关注 chatgpt 的答案准确性，也要关注网络信息本身的信息准确性，而网络已经在我们身边存在几十年了。
过去，我们获取信息靠的是书本、论文、前辈的经验。现在，我们越来越倾向于靠网络搜索，但我们无法准确预知这些信息的正确性，但单纯的从信息来源的审查角度来看，书籍论文的审查制度和网络文章的发布约定相比，要严格的多，一定程度上，前者的信息可靠性一定更好。
看到一个观点：“我们在接收信息时，一定牢记：事实 > 观点，框架和逻辑 > 结论。” 遇到有质量的长文时，不要急功近利的去读它的简化版、缩水版，尤其是那种吸引流量的标题党，这种信息最容易断章取义、添油加醋，让有效的信息失真。
回到开始的话题。我们不要只看到 ChatGPT 这种新人工智能中出现的信息失准问题，也要努力去看到现在网络世界中的信息失准问题，归根结底，不要轻信没有依据的观点，培养主动探索问题本源的能力，才是我们真正要关心的事情。
转载自我自己的微信公众号：目的地，欢迎关注。
在芯片尚未流片，硬件还停留在前端设计时，芯片公司里那些软件开发工程师，已经在一个虚拟的环境上运行起了程序和算法。这个神奇的虚拟环境，就是计算机体系结构模拟器。
前几年，苹果公司在着手开发自研 M 系列处理器时，他们的软件工程师们，并不需要等到自家的芯片从工厂生产出来寄到公司，就能够让新的 MacOS 系统在新硬件上运行起来；而 Intel 的工程师们，他们在针对不同硬件上设计缓存算法时，并不需要机房里运行各种型号的处理器。
这就是计算机体系结构模拟器的魅力。它是一个桥梁，连接着软件设计和硬件设计，使得芯片公司可以让软件团队和硬件团队一起开始在新项目上发力，也可以让架构师们在构想的硬件模型上，验证和优化自己的设计和算法。
简单来说，计算机体系结构模拟器（以下简称模拟器）是一套软件，这套软件用来重建一台计算机硬件。它可以精确或近似的模拟目标硬件的执行行为，让上层程序以为自己真的运行在一个硬件上。
每一项技术的诞生都有其存在的理由，模拟器的存在用来解决在硬件开发中的几个关键痛点。
传统的硬件开发流程是先进行硬件设计，制造原型，原型测试，流片，硬件点亮，软件研发。其中还要考虑硬件测试的各个环节出现回退的问题，所以通常一款硬件从设计到回片，可能要经历一年到一年半的时间。软件研发如果等待硬件回片后进行，那么实际产品推出的时间只能更晚。
另外，硬件流片的成本很高，动辄几百万美元，如果回片后无法点亮，发现存在系统性故障，重新流片带来的经济损失也将很高。
引入模拟器后，无论对于硬件工程师，还是软件工程师，都具有很大的帮助。硬件工程师可以先在模拟器上进行设计和初步验证，并与硬件仿真的结果做对比，最大可能避免后期生产时的回退。
而软件工程师则可以不用等硬件生产回片，而是在硬件前端定型后，就开启相关的开发工作，软件的开发和调试，可以利用模拟器作为运行环境来完成。由于模拟器足够灵活，所以实际上软件开发在模拟器上调试要比在硬件上调试也更为便捷。
实际的芯片，对于软件来说，基本是一个黑盒子。软件只能看到输入和输出，除此之外唯一能依靠的就是调试接口（研发早期调试功能也不是最紧迫的）。
软件无法洞察到硬件的细节，而模拟器则提供了另一个思路。
模拟器可以任意设断点、单步运行和回退；模拟器可以打印出任意寄存器、内存、信号量、缓存等信息，甚至软件运行过程中的整个快照；如果有需要，模拟器可以任意调整硬件配置（比如缓存大小）。这些功能都并不依赖于调试工具就可以实现。
另外，模拟器对于一些软件导致的随机问题，可能更容易复现，在一些极端测试下，也更容易发现隐藏在角落的问题。这些功能，让模拟器对软件来说，就像是对硬件开启了 “透视”功能，极大方便软件的开发工作。
实际上，现在很多云服务，提供的都是虚拟设备，也就是模拟器的一种，它们将软件服务和硬件设备进一步隔离开，避免了软件的问题直接破坏物理设备。同时，虚拟运行也可以更方便的发现运行问题。
模拟器作为一类软件，在不同的场合下，其应用方式不同，所以做的也并不是同样的事情。根据不同的需求，工程师们开发了不同的模拟器类型，用于解决各种现实问题。
第一种叫微体系结构模拟器。微体系结构是介于处理器体系结构和硬件设计之间的一层，它可以将硬件功能进行抽象。微体系结构模拟器则用来在这一个层面上对硬件功能做模拟。
比如说，它可以专注于模拟流水线行为、缓存行为等，这种模拟器可以计算出分支预测的准确率和缓存命中率，并完整地展现出每一次运行的通信细节。
2000 年初，斯坦福大学的研究人员，使用 SimpleScalar 模拟器，改进了分支预测算法，这个算法后来用在了多个商业处理器上。SimpleScalar 是一个微体系结构模拟器。
第二种叫系统模拟器。它则模拟整个计算机系统，除了处理器本身，它还负责去模拟内存、磁盘、I/O 设备等。这类模拟器强大到其自身就可以启动一个操作系统，并与其他模拟器或硬件设备协同工作。
模拟器设计中一个永远逃不开的话题，就是更重视速度还是精度。基于此，可以将模拟器分为：功能模拟器、周期精确模拟器和事件驱动模拟器。
功能模拟器只保证结果正确，它在一个较高的尺度下完成硬件模拟，通常在项目的早期会被使用。由于模拟精度不高，所以其运行速度相对较快，可以在 10-100 MIPS 之间。
周期精确模拟器则刚好相反，它可以模拟每一个时钟周期的行为，所以它对硬件细节的刻画最细致，可以用于性能评估、缓存优化等。由于它选择了精度，在运行速度上相对更慢，在 0.1-1 MIPS 之间。
事件驱动模拟器则刚好介于两者之间。它基于硬件事件来仿真，比如网络通信、系统互联等。它的运行速度在 1-10 MIPS 之间。
不过，无论哪种模拟器，都不可能达到硬件的运行速度（通常在上千 MIPS 甚至更高）。
指令集模拟器是一种功能模拟器。它专注于一个重要的目标：正确模拟指令的行为。它既可以去精细地按照硬件行为去实现指令，也可以按照逻辑算法来实现指令，最终只保证指令确切的输入，可以产生确切的输出。
更细节一些，指令集模拟器的实现分为几种思路：
| 实现技术 | 工作原理 | 速度 | 灵活性 |
|---|---|---|---|
| 解释执行 | 每读取一条指令，解析一条指令 | 慢 | 高 |
| JIT | 它预先将目标代码块翻译成本机代码后执行 | 中 | 中 |
| 虚拟化 | 利用 CPU 硬件虚拟化技术，来模拟目标程序 | 快 | 低 |
值得一提的是，模拟器并不一定需要模拟某个硬件，也可以作为软件的一套运行时环境。比如 JVM 也是模拟器的一种。
虚拟化的灵活性最差，这是因为虚拟化需要目标程序的硬件架构，和运行模拟器的计算机架构（也就是提供虚拟化的硬件）保持一致。
即便是解释执行的方式，在指令集模拟器类型里表现效率较差，但在各种模拟器类型中，由于它模拟的精度低，反而运行效率不一定差。
Spike 模拟器是一种指令集模拟器，他是 RISC-V 官方的参考模拟器，它提供了一套标准化的验证平台，硬件工程师用它来验证自己的实现是否符合标准，软件工程师用它来开发对应的软件。
大多数人认为，在芯片公司，模拟器的价值在于 “在硬件回来之前就开发软件”，但这只是其中一方面。
模拟器的能力很强大，功能很灵活，所以它实际上有很多潜在的价值。
软件上有一些可能概率性复现的问题，比如说多线程的竞争问题。在硬件上运行时，由于硬件运行速度快，反而这种竞争问题难以复现（比如跑 100 次出现一次），这对于软件开发工程师来说，就变得非常棘手，难以复现问题便难以调试问题。
模拟器的运行速度不快，再加上其实现中，物理世界的概率对逻辑的影响更小，所以同样的问题程序，再模拟器上可能更高频的复现，从而帮助软件调试。
芯片设计并不是完美的，每一版芯片都可能带有一些 errata（硬件缺陷）。而模拟器能做的，就是屏蔽或灵活开关这些 errata，从而可以有助于重现硬件 bug，帮助工程师理解和修复这些问题。
另外，模拟器也支持注入异常，比如在特定的内存中插入异常数据，或主动发出硬件信号，这都有助于软硬件开发过程中，测试和调试一些边缘问题。
芯片对于软件的运行相对是宽容的，比如对于一些未配置的值，未定义的行为，未初始化的内存，硬件会尽量选择静默处理，避免系统失效。而这些潜在的问题被掩盖，对于软件来说，可能不是预期的。
模拟器则完全没有这个顾虑，它可以对各种软件行为做检查，相对于硬件来说，它更像是严厉的替身，将各种软件意外的行为捕获并抛出来。
虽然现在的芯片，也会提供一定的性能分析能力，但能做的依然比较有限。
硬件可能能够提供一定程度的采样、总体的缓存统计以及有限的内存访问分析，而这些硬件机制还需要基础软件去配合来发挥其能力。
而模拟器则可以灵活地提供这些功能，它可以捕获每一条指令的运行状态，对仿真组件的影响，每一次访存动作、缓存命中情况等。进而，对于性能分析的工作提供有利的参考。
虽然模拟器不能提供准确的绝对数据，但提供迭代改进的相对数据和横向对比数据，也非常有价值。
对于一些公司，它们需要在硬件发售之前，先将软件交付给客户，为了能保证用户使用软件时正常运行调试，就需要一并把模拟器也发布出去。可能有不同的形式，比如交付二进制产物，或者提供云平台接入等。
另外，即便硬件已经能够交付，一些用户也希望自己购买的软件产品中能带有模拟仿真的功能，比如 IDE（软件集成开发环境）中带有模拟运行特性，这也需要模拟器团队去接下重担。
模拟器不是万能的，它在软硬件设计这个场景下，能够发挥出自己的优势，但确实也存在一些局限性。
最主要的就是速度。如果对硬件做详细的模拟，就不得不面对测试效率越来越低的现实。这种和硬件的差距，可能达到几千上万倍，以至于对于使用者来说无法容忍。毕竟，软件输入数据的规模，也影响着一次运行的总用时，越来越复杂的软件需求和硬件设计，使得模拟器夹在中间，迎来更多的质疑。模拟器开发工作中确实挺让人头大（笑哭）。
其次是准确性的问题。模拟器毕竟只是一套软件，它无法完全复刻硬件的行为，模拟器开发工作中的绝大多数维护时间，都用来去与硬件做参照。过于准确的设计又反过来带来了速度的损失，需要不断寻求平衡。
最后是新兴硬件越来越复杂，比如异构架构，而软件的需求也越来越高。比如在一个 GPGPU 公司做模拟器，来运行行业上各种大模型和算法。这对模拟器带来了新的机遇和挑战。
| 工具 | 类型 | 特点 | 应用场景 |
|---|---|---|---|
| QEMU | 系统模拟器 | 支持丰富的硬件架构，社区活跃 | 虚拟化、嵌入式、操作系统移植 |
| Gem5 | 微架构模拟器/全系统模拟器 | 高自由度、研究导向 | 计算机架构研究、性能分析 |
| spike | RISC-V 指令集模拟器 | 官方模拟器，简单易用 | 生态软件开发、教学 |
| Bochs | x86 系统模拟器 | 移植性强 | 操作系统开发 |
| LLVM simulator | 指令集模拟器 | 基于 LLVM | 编译器测试 |
| SPIM | MIPS 指令集模拟器 | 简单易用 | 教学 |
计算机体系结构模拟器，这个隐藏在芯片设计和软件设计背后的强劲工具，是软硬件快速发展的翅膀。虽然大多数人并不会注意到这个领域和这些工程师，但它们实实在在的在默默支持着一线。
本文同步发布在知乎账号下：计算机体系结构模拟器简述
标题图片使用豆包 AI 生成，提示词：冬天、白雪皑皑的冰川、毛毡画、16:9 画幅。
中医并不代表着落后，西医也不总代表着进步，这是一个特别大的误区，并且很多人都这么认为。落后的是传统中医和西医，进步的是现代中医和西医。曾经的西医，也需要尝草药，抹药酒，放血疗法；现代的中医，也会用设备监控身体状况，用仪器分析药理成分。
我们要在科学的背景下选择性的看待中医和西医。
晋太元中，武陵人捕鱼为业。缘溪行，忘路之远近。忽逢桃花林，夹岸数百步，中无杂树，芳草鲜美，落英缤纷。渔人甚异之。复前行，欲穷其林。
林尽水源，便得一山，山有小口，仿佛若有光。便舍船，从口入。初极狭，才通人。复行数十步，豁然开朗。土地平旷，屋舍俨然，有良田美池桑竹之属。阡陌交通，鸡犬相闻。其中往来种作，男女衣着，悉如外人。黄发垂髫，并怡然自乐。
见渔人，乃大惊，问所从来。具答之。便要还家，设酒杀鸡作食。村中闻有此人，咸来问讯。自云先世避秦时乱，率妻子邑人来此绝境，不复出焉，遂与外人间隔。问今是何世，乃不知有汉，无论魏晋。此人一一为具言所闻，皆叹惋。余人各复延至其家，皆出酒食。停数日，辞去。此中人语云：“不足为外人道也。”
既出，得其船，便扶向路，处处志之。及郡下，诣太守，说如此。太守即遣精卒随其往，携刀循所志往。
至山口入，村人见甲士，皆持耒耜拒之。喝令降，不从。遂纵火焚屋，相攻竟日。男丁死者相藉，妇孺多掳，鲜血漫浸林麓，沾濡桃花。
事毕，召渔人，予金帛胁之缄口，令毁途志，对外云：“寻向所志，遂迷而不得路”。
南阳刘子骥，高尚士也，闻之，欣然规往。桃林尚在，然溪间浮尸残木，岸侧焦垣断壁，腥气绕林。枝头桃花，尽染赤黑，风过簌簌，如泣如诉。后每每梦入桃林，满树黑花，触之粘腻如血，惊起汗透重衾。未几，寻病终。后遂无敢问津者矣。
本文后半部分为我的杜撰，感谢你愿意读完。
原文末尾为：
既出，得其船，便扶向路，处处志之。及郡下，诣太守，说如此。太守即遣人随其往，寻向所志，遂迷，不复得路。
南阳刘子骥，高尚士也，闻之，欣然规往。未果，寻病终。后遂无问津者。
《桃花源记》是陶渊明的一篇著名文章，事实上桃花源是否在历史上真实存在，无从考证，由于陶渊明是一个理想主义者，所以他大概率会编写这样一个乌托邦的世界，来寄托自己的思绪。
不过，如果假设桃花源真实存在过，那么更现实主义一些猜测，结果很可能是我上边杜撰的结尾。渔人擅长寻路，而且寻向所志，不太可能找不到桃花源，更不可能迷路。另外，陶渊明所处的东晋末年，战乱不断，官府急需兵卒和粮食，发现桃花源的结果一定是管理和征税，而来自秦末就与世隔绝的桃源人，是断然不可能服从的。
这也就更容易解释，刘子骥为什么因为没找到桃源，就因为寻找而得病甚至病死。显然，看到梦想中美好的桃源是如此惨状，更容易引发精神压力和疾病。而后人无问津者，不是不再好奇，更可能是不敢问。
这个桃源二创的点子，来自于早期高分国产剧集《毛骗》，推荐观看。
]]>这一章有两个对更具体话题的讨论，虽然不适于普适的应用场景，但通过阅读学习，也能一定程度上加深对 C++ 编程语言的理解。作者发挥了他一贯的先假设再否定的行文风格，如果先验知识不足，很可能跟不上思路。
条款标题很长，因为这个条款的前置条件很多，只有在这些前置条件都满足的情况下，才可以考虑将一个形参按值来传递。
阅读下文之前，需要已经明确搞清楚以下几个概念：
和前边一样，我不会按原文的行文顺序去复述，而是按我理解地最容易被读者接受的顺序来介绍。
首先我们梳理下条款要说明的内容。我们知道，函数形参的传递方式，可以分为按引用（包括按指针，这里不讨论）和按值传递。为了保证参数传递的效率，通常会建议对于用户自定义类型或者复杂的容器类型使用按引用传递，避免拷贝数据带来的开销。
本条款想提出一个建议，如果一个类型作为形参时，无论它的复制成本有多重，当同时满足以下条件时，可以按值传递：
下边给出要讨论的示例代码，我们需要实现一套普通成员函数：
1 | class Widget { |
示例中给出了三种实现，我们依次对这三种实现的参数传递代价做分析：
方案 1，通过引用传递参数，因为调用方的实参是通过引用传入被调用方形参，所以没有复制或移动的成本。在左值引用形参的重载版本中，引用形参 newName 通过复制传入 names；在右值引用形参的重载版本中，引用形参 newName 通过移动传入 names。
方案 1 成本合计是，对于传入左值实参，发生一次复制，对于传入右值实参，发生一次移动。
方案 2，通过万能引用传递参数，实参到形参的过程，依然没有复制或移动的成本。由于 std::forward 的操作，实际内部传入 names 时的行为，和方案 1 没有区别。
方案 2 成本合计同方案 1，对于传入左值实参，发生一次复制，对于传入右值实参，发生一次移动。
方案 3，按值传递参数，从调用方的实参到被调用方的形参过程中，无论是左值还是右值，都会进行一次构造，如果传入左值，发生一次复制构造，如果传入右值，发生一次移动构造（std::string 有移动构造，我们也假设本条款讨论的类型有移动构造）。在函数体，newName 一定会通过移动传入 names，因为 newName 作为局部变量，后边没有调用了。
方案 3 成本合计是，对于传入左值实参，发生一次复制一次移动，对于传入右值实参，发生两次移动。
这么看来，似乎方案 3 一定比方案 1 和方案 2 代价更高，无论左值还是右值，都会多一次移动操作。但回头看一下本条款的前置条件，其中包括 “移动操作成本很低”。也就是说，从上边的成本分析来看，满足条件的类型，使用方案 3 和使用 方案 1 或方案 2 的性能开销基本是相同的。
但使用方案 3 带来了什么好处呢？方案 1 中，我们需要编写多个类似的重载函数，代码更冗余，不利于维护；方案 2 虽然避免了方案 1 的问题，但使用万能引用又带来了其他问题，具体可回顾条款 26。方案 3 此时就有了用武之地。
解释完条件二的成本代价，我们回头再分析下条件一，为什么是必要的。
对于只移形参来说，使用上文的方案 1，通过重载的方式，因为只移对象没有复制构造函数，所以我们只需要编写一个接受右值引用的形参的重载版本即可。
那么，使用方案 1 最明显的代价，也就是编写多个重载版本函数的问题，也就不存在了，反过来说，使用方案 3 针对方案 1 的优势也就不存在了。此时，方案 3 还存在着额外移动一次的成本，总体就不值得推荐了。
这一条是表述歧义最大的一条，虽然我极力想要换一种描述方式，但并没有找到同样简略的用词，所以保留了书中翻译版本的结果（这里的 “复制” 二字是歧义的来源）。
条件三的 “一定发生复制” 是指，形参一定会被用于移动到另一个容器中，也就是上例中，newName 一定会被移动到 names 容器中。
书中给出的违反条件三的例子是，假设在将 newName 移动到 names 之前，先判断 newName 的长度，只选择一个范围内长度的 newName 才执行移动：
1 | void addName3(std::string newName) { |
当一个输入参数，长度不满足 [minLen, maxLen] 区间，那么就不会执行移动到 names 的操作。此时，如果换成引用传递参数，则不会带来任何开销，但使用按值传递参数，则仍然有构造的开销，从而放大了按值传递的缺点，不值得使用。
总结一下：
| 阶段 | 按引用传递，重载函数 | 按引用传递，万能引用 | 按值传递 |
|---|---|---|---|
| 形参构造阶段 | 无代价 | 无代价 | 左值一次复制构造，右值一次移动构造 |
| 形参传入容器 | 左值一次复制构造，右值一次移动构造 | 左值一次复制构造，右值一次移动构造 | 一次移动构造 |
当三个条件都被满足时，使用按值传递参数，其代价才是可接受的。
前边讨论的是，使用 std::vector<T>::push_back 来实现对形参的处理，push_back 内部，会直接在容器堆内存的末尾创建新元素的空间（这里不考虑扩容时重新分配内存的问题），然后把数据拷贝到新元素空间（通过复制构造或移动构造）。
但是，如果我们不使用构造的方式，而是使用赋值的方式来操作形参呢？考虑以下示例（我们这里假设实参一定是左值，省略右值的讨论，左右值实参的区别可见上文）：
1 | class Password { |
两个方案中，都使用了赋值的方式来使用形参，但方案 1 是按值传递参数，方案 2 是按引用传递参数。两者有什么区别？
对于方案 1，传递参数时，调用一次构造函数（左值调用复制构造，右值调用移动构造），赋值 text 时，调用一次移动构造；对于方案 2，传递参数时，不会发生成本，赋值 text 时，调用一次构造函数（左值调用复制构造，右值调用移动构造）。
然而我们要讨论的重点是进一步的话题。如果 text 之前已经有值，也就是 std::string 类型的对象，已经分配了一块堆内存来存放之前的一个旧密码。那么，如果新密码比旧密码长，会发生什么？反之如果新密码比旧密码短，会发生什么成本？这里我们不考虑 std::string 的小字符串优化，假设数据一定被存放在堆空间中。
对于方案 1，当新值比旧值更短时，调用 change1，形参 newPwd 通过构造函数创建，发生一次堆内存分配和一次内存拷贝。在函数体内，因为是移动赋值，通常的实现是 text 中指向堆内存的指针由之前的旧密码空间，改为指向新密码空间。之前旧密码空间被释放，没有额外构造成本。
当新值比旧值更长时，调用 change1，形参 newPwd 通过构造函数创建，同样发生一次堆内存分配和一次内存拷贝。在函数体内，同样直接通过移动操作，没有构造成本。
对于方案 2，当新值比旧值更短时，调用 change2，形参通过引用传递，没有额外构造成本。在函数体内，发生拷贝赋值，由于新值更短，直接使用原旧密码空间，不用重新分配内存。
当新值比旧值更长时，调用 change2，形参构造同样没有成本。函数体内，原旧密码空间不足以存放新密码，所以需要重新分配空间，然后释放旧密码空间，并使用拷贝赋值填充新密码数据。
总结一下：
| 阶段 | 按值传递，新值更短 | 按值传递，新值更长 | 按引用传递，新值更短 | 按引用传递，新值更长 |
|---|---|---|---|---|
| 形参构造阶段 | 一次分配空间、一次拷贝构造（左值实参） | 一次分配空间、一次拷贝构造（左值实参） | 无代价 | 无代价 |
| 赋值阶段 | 无代价 | 无代价 | 一次拷贝赋值（左值实参） | 一次分配空间、一次拷贝赋值（左值实参） |
很清晰地可以看出，若按值传递参数，那么分配空间是一定会发生的，无法重复利用之前旧密码已经开辟的堆空间。而按引用传递参数，当新数据比旧数据短时，可以避免重新分配空间。
这是一个潜在的性能陷阱，只有在特定的输入时，即新值比旧值更长、没有触发小字符串优化时，才会发生。
采用按赋值的方式使用形参的函数，按值传递参数的代价，取决于左值和右值的成分和类型是否要按动态分配内存。当然还涉及到赋值运算符的实现，以及输入参数对空间的需求与原始动态分配空间的大小之间的关系。对于 std::string 这种类型，还需要考虑优化的影响。
按值传递参数带来的成本是很复杂的，本条款就是借此来展开讨论。通常情况下，惯用的做法是，优先使用重载或万能引用的方式，使用引用传递参数，除非一定要在这里去探究性能差异，才去考虑是否能满足本条款的三个条件，从而生成更有益的代码（改善引用传递参数实现的不足）。
原文末尾还有一段，讨论了按值传递参数时，如果实参是派生类类型，形参是基类类型时，传递参数带来的类型退化问题。这也是按值传递参数的一个缺点，我认为和本条款关系不大，也比较简单，不展开介绍。
一个老生常谈的话题了。对于很多 C++ 标准容器，通常会提供 emplace 和 insert 两种操作，比如对于 std::vector 会提供 emplace_back 和 push_back 这两种将元素追加到容器队列结尾的操作。
本条款讨论了这两种不同的操作之间的差异，以及各自适用的场合。由于我实在没有找到更合适的 emplacement 的中文翻译，所以选择了中文译本的 “置入” 一词（虽然平时完全不会这么说）。
首先最基础的一点，想必大家都了解。插入类的操作，是将一个对象以移动或复制的方式，放在与该对象类型相同的容器元素类型容器中；而置入操作，是在容器的选定位置，直接构造一个该对象类型的对象，传入的是类型构造函数的参数而非类型本身。
比如说：
1 | std::vector<std::string> vec; |
a 操作为插入操作，其实等价于：
1 | vec.push_back(std::string("abc")); |
b 操作为置入操作。两者的区别是，a 操作会在传入实参前，做一次构造创建一个临时对象，因为是右值，所以通过移动构造传入 push_back 形参后，临时对象被析构。b 操作不会有这种动作，而是直接在容器末尾通过构造函数创建一个对象。
在这个例子中，使用置入要比使用插入效率更高。emplace 函数使用了完美转发，所以并不会带来右值参数传入时的额外成本。反过来，如果对于插入函数并不会创建临时对象的情况，使用置入函数，通常也不会有问题，置入不会带来额外成本。
不只是 emplace_back，任何支持 push_front 操作的容器，也都支持 emplace_front，任何支持 insert 操作的容器，也都支持 emplace 操作，任何支持 insert_after 操作的容器，也都支持 emplace_after 操作。
虽然这么说，但上边我还是把 “通常” 加粗了。理论上来说，置入能完全取代插入，避免性能问题，但这只是理论上，如果想确定哪个更好，定量分析还是需要做基准测试。
定性讨论的话，书中提到，满足以下三条情况，使用置入操作替代插入操作是没问题的：
std::vector, std::string）。它们以构造的方式添加值（而非赋值的方式），插入会带来额外的临时对象构造，但赋值的方式添加值，临时对象无法省略；还有两个场景，置入函数不值得推荐。
第一个场景是有关于资源管理时发生异常导致资源泄漏的问题。假设我们有一个管理智能指针的容器：
1 | std::list<std::shared_ptr<Widget>> ptrs; |
在之前条款 21 中提到，如果在指定 shared_ptr 智能指针时，还需要指定自定义析构器，就不能使用 make_shared 函数来辅助，但如果不使用 make_shared 函数，就可能遇到发生异常时资源泄漏的问题。比如说：
1 | // 这是自定义析构器 |
当在插入到容器时发生异常（比如内存不足），两种实现有什么差异呢？对于插入来说，由于会产生一个临时对象，所以 new Widget 的内存指针会保存在临时对象中，如果 std::list::push_back 插入失败，会调用这个临时对象的析构函数，从而将分配好的内存释放掉。
对于置入来说，new Widget 的内存指针直接通过引用方式传入 emplace_back 中，当容器内插入时发生异常，没有能调用的析构函数，异常直接会被抛出外边，内存指针被彻底丢失，发生内存泄漏。
在这种情况下，建议使用插入而不是置入。当然更合理的做法是正如条款 21 中所言，将 new Widget 的结果单独保存成一个对象，再将对象以移动的方式传入插入或置入函数中。只要资源作为栈对象被命名，那它最终会被析构。
另一个场景是有关于带有 explicit 修饰的构造函数类型的情况。说实话作者想的是真细。
具体来说，有一些类型定义中，有些构造函数使用了 explicit 来修饰，这意味着它的这种构造方式，只允许通过显示调用的方式来访问，这就暴露了插入和置入两者的区别。书中的例子很有趣：
1 | // 保存正则表达式的容器 |
编译器允许置入一个空指针，但不允许插入一个空指针。虽然，用空指针构造 std::regex 类型本身是没有意义的，但标准库中支持，原因是 std::regex 实现了一个由 const char* 作为形参的构造函数。本身它是为了支持将字符串形态的正则表达式构造为 std::regex，但却没有将 nullptr 排除在外（也是指针，可以传给 const char*）。
由于这个构造函数使用 explicit 来修饰，所以只能显式调用。而插入操作中，从 nullptr 到 std::regex 中间，使用了复制初始化，隐式调用了构造函数，所以编译器报错了。不过对于置入操作，它将 nullptr 传入 emplace_back 内部后直接调用了构造函数，所以编译器没有报错。
谬误：置入函数一定比插入函数更推荐使用。
翻开最后一页，发现是空白了，又读完了一本书。总体来说，这本书的内容很不错，对于有一定基础的 C++ 开发者来说，是一个查漏补缺的机会，我收获很大。期待 Scott Meyers 能出下一本 Effective 系列。
本系列的其他文章：
本文同步发布在知乎账号下：https://zhuanlan.zhihu.com/p/1966160349238629902
C++11 中，提供了强大的并发特性，使得我们在编写并发程序时，不需要再去调用操作系统提供的并发接口（如 pthread 和 Windows 线程库）。Modern C++ 的程序员，必须熟练掌握并发 API 的用法，本章节会展开讨论几个使用 C++ 并发 API 时需要考虑和注意的问题。
如果想要以异步运行的方式启动一个程序，有两种 API 可供使用：
1 | int doSomeAsyncWork(); |
两种方式各有不同的特点。书中介绍的什么是线程、什么是硬件线程和软件线程，这里不再重复赘述。
std::thread 就是启动一个软件线程，交给操作系统去调用执行。简单点来看，就是以一个独立的线程去执行这个异步函数。std::async 创建的对象 fut 的类型是 std::future，它的底层实现，也是一个软件线程，但它能做到的更多。
首先，std::async 可以返回一个期值 future，它作为一个对象，可以在之后通过 get() 等 API 来访问这个异步任务的返回状态，包括异步函数的返回值，和运行的异常。然而 std::thread 很难做到，std::thread 可以通过线程通信的一些方式（比如共享内存）来做数据交换，而其异常也无法在线程外部捕获到。std::async 也可对任务的状态做更详细的控制（如控制任务延迟启动，任务生命周期和 future 对象绑定）。
操作系统对软件线程的数量是有限制的，如果启动操作限制的数量，会导致线程启动失败，std::thread 会抛出 std::system_error 异常。而 std::async 默认的行为是，当软件线程超出限制时，采用同步的方式去执行这个程序，从而避免抛出异常。当然，也可以传入配置，要求 std::async 必须以异步方式执行程序。
即使没有超出操作系统限制，当软件线程数量大于硬件线程时，操作系统为了让所有线程都有机会运行，会对 CPU 做切片，按不同的时间片去以合适地调度策略去执行这些线程。虽然这种行为很常见，但线程数量过多（比如我之前做过的一个测试程序，要起很高的并发度去运行测试用例）时，还是会很容易触及性能瓶颈，因为过于频繁的线程切换，会带来额外的负担。std::async 会代替你去面对这种调度和负载均衡的问题。
所以，如果使用 std::thread 去编写一个多线程程序，我们会很容易触及操作系统线程管理的领域，比如是否要考虑硬件线程资源的数量，操作系统中其他进程的运行状态，我们的整个程序中，需要小心谨慎地处理线程耗尽、线程调度和负载均衡。而使用 std::async 则得心应手很多。
当然，有几种情况，依然需要使用 std::thread。
std::thread 提供了这种机会，而 std::async 则没有；std::async 没有支持的线程计数时，如手动实现高性能线程池；这些都不常见，优先选择，依然是使用 std::async。
上一个条款中提到，std::async 并不总是会以异步的方式启动程序。这是因为，它为了保证如果线程负载超出操作系统限制之后，不要抛出异常，所以会在合适的情况下，采用同步的方式去执行程序。
如果我们的应用依赖于这种异步的假设（比如盲目地将 std::thread 替代为 std::async），那可能会在一些极端情况时出现问题。
首先，了解下 std::async 的启动策略，它有两种模式：
std::launch::async：这种策略要求必须以异步的方式启动程序；std::launch::defered：这种策略，要求在 std::async 返回的期值对象，调用其 get 或 wait 接口时，才启动程序，也就是同步且延迟执行的策略。可以在使用 std::async 时，通过这个枚举来指定启动策略：
1 | auto fut1 = std::async(std::launch::async, f); |
如果什么都不指定，那就是让 std::async 的实现自己去有策略的选择二者之一。通常的方法是，优先选用 std::launch::async 异步执行程序，如果线程负载超出操作系统限制，那就选用 std::launch::defered 延迟执行程序。
因此，如果使用默认行为，那就不要对启动的任务做任何异步的假设，也不要假设同步执行时，程序一定在当前线程环境（和 fut 定义同一个线程）中执行，这是因为，fut 对象完全可以被移动到另一个线程中，再去调用 get 接口。
如果以这种错误的假设去设计了软件，在大多数情况下，问题也并不会暴露，只有当线程负荷很大时，才有可能出现，这导致常规的测试用例难以暴露问题。
陷阱：
std::async的默认启动行为，不保证任务一定会异步启动。
遗憾的是，期值对象并没有直接的接口返回它实际的启动策略。不过，可以用另一种方式来判断：
1 | using namespace std::literals; |
通过 wait_for 或 wait_until 的接口，如果任务以推迟执行的方式启动，它们将一定返回 std::future_status::defered。
如果一定需要任务以异步的方式启动，那么在调用 std::async 时，必须显式指定 std::launch::async。书中给出了一种包装异步启动任务的函数实现，它的返回值实现值得学习一下：
1 | template <typename F, typename... Ts> |
每个 std::thread 都有两种状态：可联结和不可联结，使用 t.joinable() 接口可以判断它当前的状态。本条款介绍了一个很简单的知识点，所以我不会特别大篇幅的展开。
简单来说，如果使用 std::thread 创建了一个线程，那么，当线程对象离开作用域前，需要手动使用 t.join() 或 t.detach() 来回收线程（使其从可联结状态变成不可联结状态）。
这里需要区分两个概念，std::thread 类型的对象，被称为线程对象，它是一个 C++ 中的资源句柄，它对应的资源是一个操作系统线程（也可能不对应任何线程）。线程对象遵循 C++ 约定的生命周期和析构行为，而其对应的线程，遗憾的是，并没有默认添加到线程对象的析构函数中，并自动完成析构。
究其原因，可以分情况讨论：
join 来回收线程资源。由于 join 是一个阻塞行为，如果线程没有及时结束，那么线程对象的析构就会阻塞；如果线程永远不会结束，那么线程对象的析构（也就是父进程）行为，也将永远阻塞。在大型项目中，这种行为会产生很难调试的性能问题。detach 来回收线程资源，或者说，这种操作是主动分离线程对象和线程资源，确实不会阻塞父进程，然而，很可能带来更严重的恶性 bug。比如说，线程中通过引用操作着父进程中的一些临时对象（比如栈），如果父进程通过 detach 提前退出并销毁临时对象，那么之后，线程依然会有可能修改这块内存空间。这种问题极难调试。标准委员会意识到了这个问题，如果主动将资源回收的任务代劳，就会带来性能问题或者潜在 bug 。倒不如开放给程序员，让软件在适当的时候，灵活地根据需求，回收线程资源。为了避免程序员忘记回收资源，C++ 规定，线程对象在析构时，如果线程还处于可联结状态，就让程序执行终止。
关于什么是不可联结的线程对象，书中有一个清单，我认为不错，可以了解一下。以下几类线程对象都是不可联结的：
join 或 detach 操作之后的线程对象书中后边部分介绍了使用 C++ 的 RAII 特性，对线程对象做一次包装，实现类似于智能指针的资源管理类型。将线程的回收动作放在包装类的析构函数中即可。实现比较简单，就不列出代码了。
让我们回到任务和期值的话题。
上一条款中，我们提到，std::thread 是一个指向实际线程资源的资源句柄，所以讨论析构和资源回收的话题时，析构 std::thread 线程对象，和释放线程（物理资源），是两个不同的操作。在 std::async 这边，也有同样的问题需要关注。
当我们使用 std::async 创建一个异步任务时（通过 std::launch::async 手动指定，或者系统自动启动异步任务而非延迟任务），系统会分配一个线程资源，并通过 std::future 期值对象来指向这个线程资源。我们可以通过期值对象来获取线程的返回值，这个返回值既不位于子线程的空间，也不位于启动任务一方的作用域内，而是放在堆上，它是另一块需要处理的资源。
如果 std::future 对象指向的是一个异步任务，那情况很简单，它一定会需要去析构这些资源。表现在运行时行为，便是 join 当前的线程，阻塞父进程直到子线程结束。
但是，还有一种情况，任务创建后，可以交给 std::shared_future 这种共享型期值，它和 std::shared_ptr 一样，也拥有一个控制块，控制块中存在着引用计数。多个 std::shared_future 对象可以指向相同的线程资源，但只有最后一个执行资源的对象（当引用计数为 0 时），才负责回收资源。
所以总结以上的情况，当启动的是一个异步任务时，期值对象的析构动作，有两种可能：
std::thread，这里对待线程的行为类似隐式 detach；join 操作回收线程，以及回收共享内存；如果最后一个期值对象走到生命周期的末尾时，子线程还没有运行结束，那么期值对象的析构操作就会阻塞。上一条款已经提到，隐式 join 会带来隐式的性能问题。但标准委员会考虑再三，还是决定在这里妥协这个问题。
这也带来了进一步的一些现象，比如下例中的情况，期值对象自己，并不知道什么时候会发生阻塞析构：
1 | // 容器的析构操作可能会阻塞 |
除了使用 std::async 来创建任务时，会产生共享的返回值资源外，还有另一种情况，使用 std::packaged_task 也可以创建返回值。它相当于是对函数的一层异步封装，封装后，对象交由 std::thread 或 std::async 可以以异步方式运行（书中的描述不准确）。
当使用 std::thread 运行时：
1 | int func(); |
可以通过 get_future() 接口来取得 std::packaged_task 的期值。也可以通过它创建 std::thread 线程对象。明显，线程对象和线程资源是分开的，所以期值对象和线程对象其实是可以同时存在的。
这就带来一个有趣的问题。考虑我们这一条款的话题，线程资源会被谁析构？
实际上，期值对象将不需要负责去析构线程资源。讨论可能的三种情况：
t 没有任何后续操作，在 t 的作用域结束时，线程是可联结的，这会导致程序终止；t 在作用域结束前，执行 join，那么 t 将负责析构线程资源，而期值对象 fut 不需要在析构时隐式 join；t 在作用域结束前，执行 detach，线程资源将由系统回收，fut 仍然不需要做任何事情。总结来说，就是如果期值对象是经由 std::packaged_task 获取，而不是通过 std::async 获取时，它的析构中，不需要负责回收线程资源。
使用 std::async 来运行 std::packaged_task 包装的任务函数，没有讨论的必要，它的析构行为和前述开头的结论一致。而且，使用 std::async 时，也不需要 std::packaged_task，它自己便可以完成函数包装的功能。
这一条款，我们开始讨论一下异步任务之间通信的问题。先来看下问题的由来。
使用锁和条件变量实现
如果你做过一定程度的 C++ 异步编程工作，那么在异步通信时，很容易会遇到以下的问题。看这个代码：
1 | // 使用条件变量和锁配合，是最常见的做法 |
这是一个很典型的面试题，考虑下其中存在哪些问题。
存在 2 个问题。首先，如果在发出事件任务执行完 notify_all() 之后，接收事件任务还没有执行到 wait(lk) 时，那么当接收事件任务最终执行到 wait(lk) 时，便会继续等待，如果后续没有新的通知过来，那将永远阻塞下去。
其次，wait 有一个叫 “虚假唤醒” 的特性，这是一个系统级的行为。简单展开来说，系统和硬件对于调度线程的成本很高，唤醒操作如果做到高精度，可能的性能代价是难以接受的，所以，在系统层面，明确指出了这个问题，并将精确接收并唤醒线程的最后确认工作交给软件完成。它不是一种 bug，虽然概率不高，但仍然需要认真对待。为了保证精确唤醒，在接收端，必须通过条件确认。
解决这两个问题的答案是统一的，也就是把 cv.wait(lk) 这一行改成：
1 | cv.wait(lk, []{ return condition_check(); }); |
当后边的 lambda 表达式中，返回值为真时，wait 将不再继续阻塞。检查条件状态，需要在发出事件的任务中，对状态做修改（比如一个 bool 值），完整的改进：
1 | std::condition_variable cv; |
这是 C++ 异步编程中，处理通信的最常见答案。在 demo 程序中，可能看起来比较清晰，但当这样一个设计模式，放在一个大型的异步程序中，多个锁、多个条件变量，以及更复杂的状态检查条件，会让程序本身开发和维护变得很棘手。
之前条款中，我们提到，创建的子任务中，返回值会通过 std::promise 类型的对象来发送，而父进程的返回值接收，是通过期值 std::future 对象来接收。
由于返回值通信并不是泛化的任务间通信，它只能通信一次，所以，本条款也明确指出，只有在一次性通信任务中，可以使用这个方案。由于我们只需要传送状态，而不需要带有任何额外信息，故而返回值的类型，只需要设置为 void 即可。
1 | // 需要共用的数据 |
这种实现，既可以解决上一节提到的通知遗漏和虚假唤醒问题，也看起来更整洁。但它也不是完美的：
如果能接受这样的问题，使用期值来实现通信也是一个不错的方案。一个完整的 demo 如下：
1 | void received(); // 实现接受事件后，需要做的事情 |
书中还提到了这里存在的一个小问题。假设在线程 t 创建启动之后，p.set_value() 之前，父进程程序发生了异常，那么 p.set_value() 不会被执行，那么子线程就会始终阻塞下去。使用第一种条件变量的方案也会遇到这个问题。
书中没有给出这个问题的答案，以下是我的个人想法，仅供参考。完整的改善代码为：
1 | void received(); |
这块代码中的几个细节。首先，在创建线程 t 之前，先获取 p 的期值 fut。这个操作很关键，在获取期值的同时，编译器会为父进程和子线程创建共享的数据区域，来存放返回值，这块区域既不属于父进程，也不属于子线程，而是独立于两者的作用域，而且，只有当两个任务都结束之后，这块空间才会被释放。
其次，将期值 fut 以移动的方式交给子线程，这样，我们就同时获得了发送端、接收端和一块独立的共享对象。当对象 p 被析构后，原来的实现中，子线程中的对象 p 的资源以引用方式（std::promise 也是一个资源句柄）捕获，便会变成悬空引用。这种改动可以避免这个问题。
最后，也是最关键的一点，std::promise 的析构函数在执行时，如果其共享对象没有被设置（没有调用 set_value 或没有发生过异常），那么析构函数会将一个异常状态 std::future_error 存入共享状态中。当任何在该共享对象上等待的操作发生时（如 f.wait()），则会立即被唤醒。
书中还建议利用 RAII 来包装线程，我认为在这个示例中没必要，如果包装，包装类对象和 std::promise 对象 p 位于相同的作用域，如果包装类的析构先于 p 的析构执行，那么又会遇到 t.join() 与 f.wait() 之间死锁的问题，还需要去处理析构顺序，就有点偏题了。
总的来说，我个人的意见是，本本分分地去使用条件变量和锁的方案为好。换成期值方案，不但有一些限制条件，而且并没有完全弱化异步编程的难度。
技巧：在某些场合下，可以使用期值特性来实现异步通信，获得特别的一些好处。
实话说，在看到这个条款时，我是困惑的，因为我从来没有想过这两个东西可以并列在一起讨论。但估计有些人确实会混淆二者，所以我考虑还是展开陈述一下。
本章讨论并发编程，所以原子操作是不应该缺席的，毕竟它太常用了，也有很多值得说道的地方。
首先，有关于 std::atomic 对象的操作，是原子的，它意味着多线程并发访问该对象时，硬件可以保证访问不会出现数据竞争，这是很简单的知识。不过需要注意，虽然对原子对象本身的操作是原子的，但如果原子操作位于另外一个非原子的表达式中，那么别把整个表达式也看作原子的。
其次，std::atomic 操作还会对指令的重排序产生限制。我们知道，编译器会做一些优化，对一些它认为没有数据依赖和控制依赖的表达式，做重排序，这样做可能会改进整个程序的性能；另外，硬件本身也有可能对指令乱序发射，它也会去分析程序的依赖性。如果我们的程序中使用了一条原子操作，那么在默认情况下，原子操作前后的指令重排序，不会跨过该原子操作。
这个地方涉及到内存模型的问题。重排序操作通常是在单线程模式下计算的，所以在多线程场景下，可能会出问题，原子操作利用内存屏障（memory fence）的机制，阻止了重排序跨过自身。
内存模型有多种不同的内存序，默认的内存序是顺序一致性，而顺序一致性保证了原子操作之前的指令，不会调度到之后，以及原子操作之后的指令，不会调度到之前。这是最强的一致性保证。
还有其他的内存序，不在这里单独展开。
做过嵌入式软件开发的同学应该都对此关键字很熟悉。它最常用的地方在于，声明一个变量是外部接口，比如内存映射的 I/O，端口，传感器等外设。它们的特点是，变量本身的读写，不完全取决于程序内部指令，还可能 “随机地” 出现在程序运行期间的任何时间点。
这种情况下，我们就不能完全按程序指令的静态假设，来对该变量做优化。比如：
1 | int x; |
其中，第一条 y=x 和第二条 y=x 在程序逻辑中，是可以通过删除第一条赋值操作来优化的；但第一条 z=v 和第二条 z=v，由于变量 v 被声明为 volatile，两条赋值操作都不会被优化。也许这里的 v 映射到了外部的传感器，而传感器每时每刻的读取值都可能不同，所以每次赋值操作都可能不同。
volatile 便是告诉编译器，不要对这个变量做任何优化。
最后总结一下，虽然看似两个概念都涉及到避免编译器或硬件操作改变程序行为，但两者的行为机制并不相同。
std::atomic 对于并发程序是有用的，它可以保证操作的原子性避免数据竞争，也能约束指令调度的范围。但它做不到声明访问特殊内存时，避免编译器优化；volatile 则相反，基本上专用于声明特殊内存，避免编译器优化；但做不到前者那些在并发程序中的用途；特别的，如果一个变量，既需要并发编程时的原子性，也刚好是个特殊内存，那么它可以同时声明二者：
1 | volatile std::atomic<int> va; |
谬误：在异步程序中，使用
volatile来修饰原子操作。
本系列的其他文章：
本文同步发布在知乎账号下：https://zhuanlan.zhihu.com/p/1962242496819098139
lambda 表达式是 C++ 中一个极具颠覆性的语言特性，它主要用于创建匿名函数，从而可以更便捷地在一些场合下，快速生成函数对象后传递给需要的位置。这一章中，会陈述几个和 lambda 表达式相关的问题。
首先，需要明确几个概念。lambda 表达式是一种语法，它是静态的，编译器处理 lambda 表达式时，会利用它生成一个闭包类，然后在利用 lambda 表达式定义对象时，利用这个闭包类生成一个闭包对象。闭包对象是动态行为。
虽然我们无法方便地知道 lambda 表达式生成地闭包对象是什么类型，但好在可以用 auto 类型来让编译器自己推导。也由于闭包对象和其他对象没有什么大的不同，也可以实现赋值和移动等操作。
所谓默认捕获模式，就是直接使用 & 或 = 捕获当前作用域中所有可以捕获的对象（按引用或按值）。本条款建议，尽量将 lambda 表达式中需要使用到的外部对象，显式写在捕获列表中。虽然无法完全避免下文可能存在的问题，但默认捕获模式，可能会带来更危险的陷阱。
一个显而易见的问题是，lambda 表达式生成的闭包对象，其生命周期可能会超出当前作用域，如果 lambda 表达式体中捕获了只在当前作用域中生存的对象，那么当被捕获对象离开作用域被析构时，lambda 表达式中的按引用捕获，实际就变成了空悬引用。
所以第一种最简单的情况就是，按引用捕获时，注意被捕获对象的生命周期，看例子：
1 | // 定义一个全局的闭包对象容器 |
这个代码中，filters 会保存多个满足类型的闭包对象（闭包对象是一种可调用类型，所以可以使用 std::function<> 来定义类型）。函数 func 中，局部对象 divisor 被按默认捕获的方式捕获到 lambda 表达式中。
那么，当在其他位置访问 filters 中的闭包对象时，闭包中的 divisor 就已经是空悬引用了，它的值是否合法是不确定的。
一个可以改进的策略便是，不要使用默认捕获模式，将需要捕获的对象 divisor 显式写在捕获列表中：filters.emplace_back([&divisor](int value) { return value % divisor == 0; });。当然，在这个例子中，这么写依然避免不了问题，但至少更容易发现问题。当 lambda 表达式体中的代码比较复杂时，默认捕获模式会更不容易看出来 lambda 表达式依赖哪些外部对象。
当你预料到情况 1 的结论，打算在之后的代码中，谨慎使用引用捕获，转而使用按值捕获，可能依然会带来一些潜在的问题。 虽然按值捕获可以让值对象采用复制方式传入 lambda 表达式体，但如果按值捕获的是指针，那么指针指向的内容仍然会随时变化，这依然是和引用捕获一样的问题。
看一个书中很典型的例子：
1 | class Widget { |
这个例子中，在一个类内，定义一个类数据 divisor，然后在类的成员函数中实现保存闭包对象到容器。看似没有什么问题，每一次创建闭包对象时，都会拷贝一份 divisor 的值进去。然而，这是误解。
捕获行为只能捕获在创建 lambda 表达式所在作用域内的可见非静态局部对象，而对于例子中的这种捕获 divisor 的方式，编译器会将指向当前类对象的 this 指针，捕获到 lambda 表达式中，也就是说，等价于 [=this](int value) { return value % this.divisor == 0; }。 那么，当 Widget 的对象，调用完 addFilter 之后，早于 filters 的生命周期而提前被析构，那 this 指针就会变成悬空指针，之后使用 filters 中的闭包，就会遇到未定义问题。
除了 this 指针，其他位于当前作用域内的普通指针，一样会遇到相同的问题。一种改善的方案便是，手动复制一份需要捕获的对象（平凡类型）到当前作用域。保险起见，也建议手动把捕获列表补充上去：
1 | void Widget::addFilter() const { |
在 C++17 中，提供了一种特性来帮助我们解决这个问题，使用 [*this] 这种捕获列表，可以允许我们将一个对象的副本捕获到 lambda 表达式作用域内，从而避免因原对象被析构后的悬挂引用问题。注意到因为这里创建了对象的副本给 lambda，所以可能会有较大的性能开销，具体选择哪个方案则因情况而定。
在 C++20 中，进一步改进了捕获 this 的特性，如果仍然使用 [=] 这种值捕获方式，将不会再包含 this 指针，如果想要捕获 this，需要手动写入捕获列表：[=, this]，这避免了上述可能存在的问题。
感谢 @机械索尼克 的补充。
lambda 表达式除了可以通过捕获来使用局部变量和形参，也可以直接使用静态对象（和普通函数一样），也就是定义在全局或名字作用域中，或者是类中和函数中以 static 修饰的对象。这种静态对象，不是通过捕获来访问的，但却会给人以错觉，认为是捕获访问。
1 | void func() { |
这个例子中，lambda 表达式使用默认值捕获，但实际上它什么也没有捕获，divisor 对象只是因为 static 属性而被直接访问的。这样，每次调用 func 函数时，divisor 都会发生变化，这可能会导致非预期的行为（我们应该是期待按值捕获 divisor，从而 lambda 中的值不会变化）。
谬误：lambda 表达式访问静态对象，并不是通过捕获方式访问。
虽然无法直接避免这种误解，但如果不使用默认值捕获方式，就更容易发现这个细节：filters.emplace_back([](int value) { return value % divisor == 0; });，没有捕获任何东西，但访问了静态对象 divisor。
综上几种情况，做个总结，lambda 表达式的捕获行为可能会让程序出现一些非预期的错误，虽然从编译层面无法规避这种问题，但不要使用默认捕获方式（包括按值捕获和按引用捕获），就更容易发现问题。
之前提到的无论是按值捕获还是按引用捕获，都无法将一个只移对象（比如 std::unique_ptr）传入闭包，C++ 11 做不到。在 C++14 中，支持了通过一种特殊的捕获方式，将对象移动入闭包。 这种捕获方式叫做初始化捕获（init capture），它可以实现除了默认捕获之外的任何捕获行为，所以也被称为通用 lambda 捕获（generalized lambda capture）。
它的语法是：
1 | auto pw = std::make_unique<Widget>(); // 准备一个只移对象 |
语法很巧妙的区分了捕获列表中 = 左右的作用域，左边的作用域在 lambda 表达式体内部，右边的作用域位于定义 lambda 表达式所在的作用域，所以可以使用相同的名称（如例子中的 pw）。
如果想要在定义 lambda 表达式时初始化对象，也可以：
1 | auto func = [pw = std::make_unique<Widget>()] { ... }; |
捕获列表中可以放置任何表达式，所以说它是一种通用捕获模式。例子中，表达式返回了一个只移右值，可以通过移动方式传入闭包。
以上是 C++14 中支持的语法，在 C++11 中，无法使用。如果 C++11 依然想要通过移动传入对象，可以用一些曲线救国的办法。
第一种办法是，手写一个可调用类型（仿函数），也就是带有 operator() 重载的类，我们知道，lambda 表达式经过编译器处理后，实际上也生成了这样一种类型。我们手动为其定义支持右值引用作为参数的构造函数，便可以在定义函数对象时，传入右值。之后使用函数对象的方法和 lambda 表达式完全一致。
第二种办法是利用 std::bind，虽然 C++11 不支持移动捕获 lambda，但支持绑定一个函数并通过移动方式传入参数。
1 | std::vector<double> data; // 准备一个对象，希望通过移动传入闭包 |
这个代码中，将对象 data 转换为右值后，绑定到 lambda 表达式中的第一个形参，以此来实现移动一个对象到 lambda 表达式中的目的。这里没有利用 lambda 表达式的捕获，所以 C++11 是支持的。
最后，要提一下，无论是 C++14 的初始化捕获，还是 C++11 的 std::bind，他们中涉及到的表达式求值，都是在定义 lambda 或绑定对象时求值。但 C++11 中，绑定对象只有在被调用时（也就是 func() 调用时），存储在绑定对象中的实参（例子中的右值 std::move(data) 经移动构造生成在绑定对象中的副本 ）才会传入 lambda 表达式中，所以事实上，lambda 表达式中操作的 data 实际上是绑定对象中的副本（注意到，lambda 表达式参数列表中的 data 类型是左值引用）。
在 C++14 中，增加了一个非常实用的特性，即泛型 lambda 表达式，它允许我们编写 lambda 表达式时，对其形参类型自推导：
1 | auto f = [](auto x) { return g(x); }; |
它类似于模板函数中的类型推导，方便我们编写泛型的匿名函数。
然而，这里要引出本条款要讨论的问题，如果我们需要将这个 lambda 表达式编写为完美转发形参，会遇到什么问题？回忆一下，使用模板函数编写完美转发函数：
1 | template <typename T> |
我们需要利用 std::forward<T> 来对形参 param 做一次转换，它的作用是，如果类型 T 是左值引用，则转换为左值引用；如果类型 T 是右值引用，则转换为右值引用。
然后，我们需要利用 decltype 这个工具，手动推导形参的类型，好在 decltype 的返回类型，也是符合预期的，当传入形参是左值时，返回左值引用，传入形参是右值时，返回右值引用。 最后，我们编写的完美转发的泛型 lambda 表达式为：
1 | auto f = [](auto&& x) { return g(std::forward<decltype(x)>(x)); }; |
考虑不定长参数列表的版本：
1 | auto f = [](auto&&... x) { return g(std::forward<decltype(x)>(x)...); }; |
对于书中对 std::forward<T> 和 decltype 在传入右值类型时的正确性讨论，我认为想地太复杂了，所以这里略掉，感兴趣的朋友可以去翻原文。
lambda 表达式和 std::bind 在大多数场景下的功能是重叠的，在 C++98 那个没有 lambda 表达式可以使用的年代，想要灵活地包装一个函数，并返回一个新的函数对象，使用 std::bind 是非常常见的做法。
然而，随着 Modern C++ 的发展，lambda 表达式的能力越来越强大，以至于可以完全取代 std::bind。
考虑一个书中的例子。现在有一个可以发出报警的函数，支持几个配置，我们希望使用 lambda 表达式或 std::bind 来包装这个函数，让其中一部分配置使用默认值：
1 | using Time = std::chrono::steady_clock::time_point; |
如果我们想包装一个可调用对象，在调用发生时刻 1 小时后开始报警，持续 30 秒，但声音类型希望调用时指定。使用 lambda 表达式的实现方案非常简单：
1 | auto setSoundL = // 'L' 表示 lambda 方案 |
然而，使用 std::bind 的方案，不但不易读，反而还存在问题：
1 | auto setSoundB = // 'B' 表示 std::bind 方案 |
首先，我们在使用 setSoundB 时，需要搞清楚它的参数，对应原始函数 setAlarm 中的哪个参数。这里，我们可以通过函数名称来确定参数是 Sound，但很多时候，尤其是有多个占位符同时出现时，唯一的办法就是去查看 setAlarm 的声明。
而且，这里还存在一个问题，表达式延迟求值的问题。对于 lambda 的版本，steady_clock::now() 的求值（当前时间），是 setSoundL 被实际调用的时候；而 std::bind 的版本，steady_clock::now() 的求值，却是在 setSoundB 被定义的地方，这可能产生 Bug。 一种改进 setSoundB 的方法是：
1 | auto setSoundB = |
虽然问题解决了，但这种写法就看起来更复杂了。
如果 setAlarm 有重载版本，比如有个带有 4 个形参的重载版本。那么 lambda 表达式依然可以正常找到正确的 3 参数重载版本，而 std::bind 则不行，会发生编译报错。
如果想继续改进 setSoundB，可以：
1 | using SetAlarm3ParamType = void(*)(Time t, Sound s, Duration d); |
也就是手动对函数做向确定函数类型方向做类型转换。
另外，这里还会引出另一个细节。对于 lambda 表达式的方案，lambda 表达式体，可以由编译器做优化，比如对 setAlarm 做函数内联；但 std::bind 却基本无法做编译器优化。最后导致 lambda 表达式的版本会比 std::bind 的版本性能更好。
对于 lambda 表达式的方案，我们想传入的 Sound 参数，可以通过按值捕获或按引用捕获的方式，在 C++14 中还可以选择按移动捕获。但对于 std::bind 则无法做到这样的自由。
std::bind 中的默认填好的绑定参数，只能按值传递，而其占位符参数，在绑定函数对象最终被调用时，只能按引用传递。如果想要写出正确的代码和高性能的代码，必须始终牢记这个设计原理。
技巧：总是试着使用 lambda 表达式去替代
std::bind的代码。
最后，总结一下，在 Modern C++ 中，完全可以使用 lambda 表达式替代 std::bind，只有 C++11 中，有 2 个场景，还是需要 std::bind，在前边条款中提到过：
std::bind 实现；std::bind 来实现；对于这两种情况，都是很少见的使用场景，而且 C++14 中的 lambda 表达式都已经得到妥善的支持。
本系列的其他文章：
本文同步发布在知乎账号下：https://zhuanlan.zhihu.com/p/1952400191220094938
在学习 C++ 时，当接触到右值引用和移动语义等概念时，就会劝退很多人。一方面，是因为这些概念本身已经不再是入门知识了，即使不懂，也可以写出一些程序了；另一方面，大多数教材中，并没有以最简洁易懂的方式完成这些知识的传授。
本章节会把这部分知识最底层最细节的内容，用另一个视角展示出来。但前提是，你需要已经理解什么是左值和右值，什么是引用这些基本的概念。
当我们写下一条赋值语句时，很多时候，实际上是完成了一次拷贝操作，也就是将数据复制一份，放入新声明的对象内存中。当数据量比较大时，并且赋值之后，原始的数据将不会再使用时，这种复制的代价会很大也很没必要。
直觉的理解，就是直接把地址复用一下，就能避免复制一份的开销，这种行为看起来像把数据 “移动” 到新的对象内存中，从而提高了性能。
在 Modern C++ 中，我们使用 std::move 这个操作，来支持移动语义。
然而，C++ 烦人的地方就在于，很多你看似显而易见的概念，实际上却暗藏玄机。比如，std::move 并没有移动任何东西，后边提到的 std::forward 也并没有转发任何东西。事实上，他们在运行期什么也不做，一个字节都不会生成。
std::move 也不一定总是能保证会产生移动行为，它实际上只是一个强制类型转换，无条件将实参转换为右值引用。
我认为，如果你敢于说出自己 “熟练掌握” C++，那么，一定可以盲写出 std::move 的实现函数，因为它真的很简单：
1 | template <typename T> |
代码中，核心是 static_cast，它将形参 param 转换为另一个类型。形参是一个万能引用，而不是一个右值引用（虽然有两个 &&），它即可以绑定左值引用，也可以绑定右值引用。函数返回的类型，首先使用 remove_reference 去除所有引用属性，然后取其类型后，再转变为右值引用，所以，返回类型一定是原始类型去掉引用之后的右值引用类型。
C++ 14 中的实现更加简洁：
1 | template <typename T> |
从源码中可以确定，std::move 确实是一个类型转换。
那为什么它和 “移动” 扯上关系呢？
我们的编译器，会在明确一个类型是一个右值时，调用这个类型的移动语义（移动构造函数和移动赋值运算符），而移动语义通常是更轻量级的实现，比如拷贝地址而不是拷贝值。std::move 帮我们确保将类型变成右值引用，从而 “尝试” 触发移动语义。
注意，我这里使用了 “尝试” 这个词，是因为 std::move 不保证一定会触发移动，因为它只能保证返回的是一个右值引用，两者之间还隔着一个编译器行为。书中一个典型的反例是：
1 | class Obj { |
这段代码中，构造函数的实参，到对象中的数据成员 value，就发生了拷贝而不是移动。原因是，构造函数形参是 const std::string，如果将一个 const 属性的数据，移动到一个非 const 属性的数据，那就会出现本不希望修改的东西可能被修改，编译器不接受这种行为，所以还是会拷贝而不是移动。
更专业的解释是，std::string 中只提供 const string& 作为形参类型的拷贝构造函数和以 string&& 作为形参类型的移动构造函数，所以 value 的构造中，被 std::move 处理后的实参 std::move(text)，其类型虽然是 const std::string&&，但在实例化 value 时，选择了拷贝构造函数（常量右值引用退化为常量左值引用）。
谬误：
std::move只保证返回的是一个右值引用，而不保证一定发生移动语义。
陷阱：针对常量对象的移动操作，一定会悄无声息的退化为拷贝操作。
理论上来说，std::move 这个命名是有歧义的，更合适的命名是 rvalue_cast 之类，然而，当时 C++ 标准委员会考虑的可能是尽可能不让用户感知更下层的细节，避免陷入语法漩涡中。我个人的意见认为，既然 C++ 无法在语法层面掩藏 “右值引用” 的概念，那就不应该在 std::move 这里多虑，选择暴露细节并让用户权衡，或者选择隐藏细节和提供封装，二者择一即可，而不是既要又要，却引入了尴尬的歧义。
同样的，std::move 看似和 “移动” 千丝万缕，但即使真的发生了移动行为，移动之后的原对象，其依然是有效的，程序员需要手动关注移动后的原对象状态，比如在移动构造中将类型成员指针赋值 nullptr。否则，状态是未定义的。
另外，一个和 Rust 对比的有趣细节，C++ 中传递非引用类型参数时，默认的行为是拷贝，若类型实现了移动语义，且实参是右值（如临时对象或手动使用 std::move 的结果），传参行为变成移动；Rust 中默认的传参行为是移动（转移所有权），当类型实现 Copy trait 或手动调用 .clone() 方法时，传参行为变成拷贝。可见，Rust 通过默认移动语义保证了安全性和性能，而 C++ 的默认拷贝行为则需要开发者主动留意安全性和性能。
比如，在 C++ 代码中：
1 | Widget w(42); |
在 Rust 代码中：
1 | let w = Widget::new(42); |
之前提到过，函数形参不可能是一个右值类型，所以，如果函数调用时实参是一个右值引用，那函数形参就丢失了右值引用属性，对于 void func(Widget&& w) 来说，当 func 内部操作 w 时，就会当作一个左值引用来处理。为了能让 func 内部的 w 也是和实参一样的右值引用，使用完美转发便可以做到。
在 Modern C++ 中，我们使用 std::forward 这个操作，来支持完美转发。
std::forward 是一个 “有条件” 的强制类型转换。只有当函数形参是万能引用类型，实参是一个右值时，会把形参强制转换为一个右值类型。
它的常用场景是，如果我们希望把调用函数时的右值实参的右值性，保留在函数内部（而不是转化为左值），就去使用它。
1 | void process(const Widget& arg); // 接受左值作为参数 |
使用时，对于 a 情况，w 作为左值传入 func，万能引用形参的模板被实例化为左值（T 的类型是 Widget&，依据引用折叠规则，param 的类型是 Widget&），所以 std::forward 什么也不会做，最终调用的是 void process(const Widget& arg) 重载版本；对于 b 情况，w 作为右值传入 func，形参被实例化为右值（T 的类型是 Widget，param 的类型是 Widget&&，注意它此时是左值），所以 std::forward 会将其转换为右值，传入 process 中，最终调用的是void process(Widget&& arg)。
如果对这块类型推导不清楚，可以回到第一章，再看看模板类型推导的规则，并结合后边提到的引用折叠来理解。
如果读完该条款，还是没有理解万能引用，那么本章后续的内容对你可能太深奥了，万能引用只是后续模板化编程的门槛石，还是先从其他地方搞明白这些概念为好。
最后做一个总结，如果你想要将一个左值尝试通过移动的方式交给函数内部，就使用 std::move；如果你在函数内，希望将外边传入的右值（函数内部变成左值），保持其右值性质，就使用 std::forward。但要记住，两者本质都是类型转换。
当我们在代码中看到一个类型的声明中带有 && 的时候，按最初的学习内容，会认为这是一个右值引用，因为左值引用是 & 来标记的。然而，还有一种叫万能引用的东西。
万能引用本身的概念很简单，它既可以绑定左值，也可以绑定右值，所以它既可能是一个左值引用，也可能是一个右值引用，具体是哪种，取决于实例化时的入参。
读懂代码，首先要能分得清万能引用：
1 | void f(Object&& param); // 右值引用 |
区分万能引用的依据是：
std::vector<T>）；有关于最后一点的简单解释，书中的示例为：
1 | template <typename T, class Allocator = allocator<T>> |
这是标准库容器 vector 的实现，其中 push_back 中的 T&& 虽然满足万能引用的语法形式，实际上却是右值引用；而 emplace_back 参数才是万能引用，Args&& 是属于成员函数自己的模板类型。
谬误：符合
T&&形式的模板参数类型，不一定是万能引用。
记住这些规则没有意义，编译器也不会去用这种类型区分什么是万能引用。事实上万能引用只是一个抽象。它的本质是引用折叠，编译器使用引用折叠规则来推导这个引用类型是左值引用还是右值引用。
引用折叠的本质是第一章中提到的模板类型推导，包括 auto 类型推导，在后边会继续介绍。
虽然万能引用是一种抽象，但依然有必要了解什么是万能引用，一方面，是可以更方便的和其他开发成员沟通，另一方面，也能更好的读懂代码，写出高质量的代码。
这一章节我看地很费劲，感觉一个很简单的知识点，翻译出来的内容非常晦涩难懂。
只要已经掌握本章节前边几个条款的介绍，这个条款的内容基本可以忽略了，都是重复的内容。
简单来说，当需要拿到一个右值引用时，使用 std::move，当需要拿到一个万能引用（也就是想要在入参的实参是右值时，才获得右值）时，使用 std::forward。
书中给出了一种错误地把 std::forward 替换为 std::move 导致的问题。
1 | class Widget { |
这个例子中，str 是一个左值，但在 setName 函数中，通过 std::move 将其转换为右值。编译器会认为，外边的 str 已经是一个无效的值，在内部调用了 std::string 的移动赋值将内容放到了成员 name 中。
将 std::move 替换为 std::forward 就可以保证不出现意外。
另外一个值得聊的话题，是返回值优化（RVO）。考虑一下示例代码：
1 | Widget makeWidget1() { |
粗略地看，我们会认为第一版函数中，返回时会发生复制构造，而第二版函数中，会发生移动构造（假设 Widget 实现了移动语义）；然而，实际上第一版中，发生了移动构造，而第二版中，发生了复制构造。
究其原因，是因为第一版代码中，满足编译器的返回值优化，编译器会在函数外边的栈上分配 Widget 的内存，并将构造直接放在外边，从而避免复制操作；而在第二版中，由于手动使用了 std::move 操作，它返回的是右值引用，编译器不得不为引用对象生成一个原始对象，从而阻碍了编译器去做返回值优化。
有关于返回值优化不是特别难懂的一个知识点，可以从其他地方了解更多细节。
重载是很常见的 C++ 应用技巧，万能引用作为一种函数形参的类型，自然也可以当作重载的一种实现，然而，当你这么做时，就开始掉入一个有点危险的坑里边。
考虑这样一个场景：
1 | std::vector<std::string> names; |
我们可能最初希望以上述这种代码来实现功能，事实上工作地很好，第一个调用是以左值传入，会执行一次复制构造；第二个调用是以右值传入，在万能引用的加持下，实际执行了 string 的移动构造；第三个是字面量，编译器事实上会利用 emplace 的移动构造，直接在 names 的内存位置构造一个 string，省去了在 func 中的一次 string 形参实例化。
然而，当我们有一个新的需求，需要添加一个重载版本的 func，问题就出现了：
1 | // 另一个同名的重载函数，形参为 int |
讨论为什么第二个调用，没有按预期调用到 func(int) 的重载版本，而是报错，便是本条款要引出的问题。
实际很容易理解，第一个调用，常量 1 会被编译器当作 int 类型，直接匹配到 func(int)，而传入 short idx，在决策使用哪个重载版本时，却使用了万能引用所在的模板函数的实例化，即：
1 | // 万能引用的模板函数，以 short 实例化后的结果 |
当编译器发现，以万能引用作为参数的模板函数，实例化后的版本，能够完美匹配时，相比于另一个 func(int) 版本还需要类型转换，自然使用万能引用模板函数的实例化更合理。而我们也发现，names 的类型，是无法接收 short 作为构造函数参数的（string 类型不能通过 short 构造），所以编译器就报错了。
实际上的编译器报错可能会输出一大串似乎没有什么用的信息，这是 C++ 模板出现问题时，不人性化的体现。于是，当编译报错出现时，很可能不太容易发现是这里的问题。
依据 C++ 规范，编译器会认为，模板实例化后的版本，没有任何的额外成本，所以这么选择是合理的，自然不能去怪编译器。所以，也就是本条款要提的主题，避免为万能引用作为形参的函数，提供重载版本。形参为万能引用的函数，是重载版本中最贪婪的。
之所以第一个版本：func(1) 没有问题，是因为 C++ 也规定了，如果模板实例化后的版本和另一个重载的普通函数是一样的，那么优先使用普通函数的版本。
陷阱：盲目使用万能引用而不顾及其他，可能会带来潜在问题。
当发现一个问题时，最好能举一反三。书中便进一步继续这个话题。当万能引用的版本作为类的构造函数，又会发生什么现象。
1 | class Person { |
这里第一眼看上去，报错很匪夷所思，我们希望调用到 Person 的复制构造函数，为什么就出错呢？
原因还是在于万能引用，我们提供的万能引用版本的构造函数，实际上可以实例化出来一个类似复制构造函数的版本：
1 | // 实例化为 |
万万没想到，本来只是打算通过万能引用的构造函数，来接收一个 name 作为参数，结果却把 Person 对象也实例化出来了。
而我们也知道，编译器生成的默认复制构造函数，其参数是带有 const 属性的：
1 | // 编译器隐式生成的复制构造函数 |
编译器在实例化万能引用的模板构造函数后，经过权衡，发现使用模板实例化的版本，不需要额外添加 const 属性，所以选择了这个模板实例化的版本。然后，我们便看到了将 name 这个 string 类型的对象，使用 Person 对象（形参）来构造，自然无法实施，导致报错。
事实上，如果调用代码中，采用以下实现：
1 | const Person p3("name"); |
问题便不存在了，原因和之前非类内的阐述是一样的。
当这个话题出现在继承结构中，也会出现类似的问题。假设有个类继承自 Person：
1 | class SpecialPerson : public Person { |
代码中，对 SpecialPerson 的复制构造函数和移动构造函数中，对 Person 的构造，实际上都调用了基类 Person 的完美转发构造函数，并都会编译失败。
在这一条款中得到的经验就是，尽可能不要去把万能引用参数的函数去做重载。在下一条款，我们会深入介绍几个技术，来迎着困难而上。
陷阱：小心不要把万能引用参数的函数去做函数重载，很可能在调用时，会得到错误的重载版本。
针对 条款 26，本条款提供了一些可以解决前述问题的替代方案。
当出现万能引用时，不要使用重载，而是用不同的函数名称来实现功能。
这是一种逃避策略，但逃避不一定意味着不好。事实上当你看完整个条款后，再回过头，会发现这种方案反而是最直接也是最推荐的做法，至少在大多数项目中，与其设计复杂的、高端的编程技巧，远不如设计简单的、易维护的代码。
既然两个特性冲突时容易有问题，除了放弃重载，自然也可以放弃万能引用。将万能引用类型全部改为常量左值引用。
这种做法失去了万能引用的性能优势，但如果放弃性能能带来代码的简洁性和安全性，也不失为一种可斟酌的方案。
虽然我们使用引用是为了改进性能，但有些时候，即便使用传值，也并不是带来额外的性能开销。在 条款 41 中会详细阐述这个问题。
实践经验中，当知道什么情况下引用类型可以改进性能时，也就有能力去判断什么情况下，传值也能带来类似的效果，反而还规避了之前的问题。
前边 3 个方案都可以认为是逃避式的方案，不过确实有一些直接解决问题的方案。
重载决议时，编译器会考察所有重载版本的形参和传入的实参，匹配全局的最优函数。既然万能引用很强大，总是能优先吸引编译器选择自己所在的重载版本，那么我们可以给重载函数多加一个参数，用额外的这个参数来制约万能引用形参的吸引力。
我们重新修改 条款 26 中的重载函数，为了保证对外接口不变，将添加额外参数的函数设置为其内部的子函数，也将重载这个内部子函数：
1 | std::vector<std::string> names; |
这个额外的形参 std::false_type 和 std::true_type 被称为 tag，基于这种方式的重载决议也被叫做 标签分派（tag dispatch）。
代码中 std::is_integral<T> 和 std::remove_reference<T> 是类型特征（type traits），之前条款中已经出现过，C++ 的类型特征很多，它们用于对类型做处理或者判断。本例子中，首先注意到第二个 tag 参数返回的是一个 “是否是整形类型” 的判断。因为类型特征是一个编译期行为，所以判断的结果，也应该是一个静态的状态，所以 C++ 标准库中提供了名为 std::false_type 和 std::true_type 这样的静态类型。注意到，这些 tag 并没有形参的名字，所以它们在运行期不会起作用，编译器会在生成程序时，去除掉这种形参（即使不去掉也不影响我们理解代码）。
继续观察 std::is_integral<T> 中的 T，为了保证无论传入的类型是 T 还是 T& 或 T&&，都应该去处理，使用了 std::remove_reference<T> 来移除引用属性。
最终，在重载决议时，如果类型 T 是一个整形，那么 tag 实参的判断就是 true_type，会选中第二个（第一个形参为 int）重载版本；否则，tag 判断是 false_type，会选中第一个（第一个形参为 T&&）重载版本。将 tag 作为重载函数参数，掩盖了万能引用影响重载决议的吸引力，最终达到我们的目的。
说句题外话，C++ 的很多复杂性的演化动力，就来自于这种不断对现有技术中的缺陷进行更多设计和改善的需求中。换句话说，不断地用一个更复杂的补丁，弥补之前的不足。
在 条款 26 中，还提到了如果类构造函数中使用了万能引用，调用构造函数时，本欲调用复制构造函数，却实际调用到了万能引用版本的构造函数。方案 4 无法解决这个问题，因为复制构造函数有可能是编译器自己生成的，所以没办法用方案 4 中，实现一个子函数来做重载。
万能的 C++ 当然考虑到了这一点，实际上，标准库中很多代码都面临这个问题，学习这块知识有助于我们去阅读学习标准库中的代码，也有助于理解和读懂编译报错时的信息。这部分会比较复杂，但也依然是类型特征的范畴。
由于没办法自己生成带有标签分派的重构函数，所以只能另寻他法，这里引出一个新的东西：std::enable_if。
如果你看过一些标准库或复杂的 C++ 项目，就应该已经熟悉它，它可以指定编译器处理一个模板实例化时的条件。默认的模板总是使能的，但如果 enable_if 中的条件不满足，那么模板将会被禁用，有关于完整的原理这里不展开（可以在网上查一下 SFINAE）。针对我们的问题，实际上，我希望在带有万能引用形参的模板中，加入这个功能，控制仅当满足特定条件时才启用该模板。下边，我们将讨论指定什么条件可以达成我们的目的。
1 | class Person { |
这段代码中的条件很复杂，如果之前没看过这个代码，也没关系，现在一起来看一下。代码按关键位置做了换行，以方便阅读。
简单来说，模板参数的第二项：typename = typename std::enable_if<...>::type 是对 enable_if 的使用，当满足 ... 中的条件时，该模板被启用；
展开里边的结构：!std::is_same<...>::value 是启用条件，也是一个类型特征，它的语义为，当 ... 中指定的两个类型不同时，模板被启用；
再继续展开：Person, typename std::decay<T>::type，指定了两个要比较的类型，第一个是 Person 类，第二个是另一个类型特征，std::decay<T>::type 的语义是，将类型 T 的引用属性、CV 特性（const 和 volatile）、数组和函数等类型，简化为最简单的形式。换句话说，比如 T& 或 T&&，const T& 或 const T&& 等等类型，经过该类型特征，输出都是 T。
总结起来，这个代码设定的就是，当某个类型 T，将其简化后（经过 decay），和 Person 不同时，该万能引用作为形参的构造函数，将被启用；否则，不会被启用。那么，针对上一个条款中的问题，当遇到：
1 | Person p1("name"); |
便可正常编译，因为 p1 被推断为 Person 类型，万能引用模板构造函数被禁用了，编译器只能找到复制构造函数。
以上我们已经开始逐步地接触模板元编程（TMP），感兴趣可以到其他地方学习。类型特征是模板元编程中一块重要的内容，可以理解为是类型的类型，在 Rust 等编程语言中，被称为特征 trait。要想熟练模板元编程，对类型特征的集合要有一定的熟悉度，这在大多数 C++ 教材中，都不会大篇幅介绍。
在继承结构中，比如 条款 26 中最后的 SpecialPerson 示例，目前使用方案 5 还是无法解决。因为 decay 无法将一个派生类型简化为其基类类型，导致 enable_if 通过。
C++ 标准当然为我们考虑到了这一点，使用 std::is_base_of 便可以处理派生类和基类之间比较的问题：
1 | class Person { |
使用 is_base_of 取代 is_same 即可。当两个类型相同的类型使用 is_base_of，如 std::is_base_of<Person, Person>，结果依然是成立的，所以可以放心大胆地取代 is_same。
对了，以上代码使用 C++14 均可以更简洁一些，结果是一样的：
1 | class Person { |
被绕了很久，已经逐渐忘记最初的目标是什么了，做一个简单的回顾。
在本章节开始时，我们介绍了万能引用的作用，而在 条款 26 中，却提出了当万能引用函数和重载、或者和构造函数一起出现时，会遇到的棘手问题。在本条款中，提出了几种简单的和复杂的方案，去解决这些问题。
最后的结论依然是，如果可以用前边几个简单的方案来解决这些问题，那么就去用便好了，在工程实践中，追求技术的专业和高效并不是最优的，代码的稳定性和可维护性才是更重要的事情。如果你是在编写库代码、做技术研究，或者单纯地就是想追寻极致的代码之美，试试模板元编程也并不为过。
但需要注意，C++ 一个极其让人诟病的地方就是它的报错很可能非常复杂，问题点夹杂在冗长的编译报错消息中，难以检查，即使你不去自己使用这些高深的技术，只要使用了标准库，也很可能会体会到，或已经深受其害。如果去使用这些技术，那么就要做好充分的心理准备，去面对恐怖的报错清单（C++20 的 Concept 一定程度上缓解了这里的烦恼）。
唯一值得安慰的是，当你掌握这些技术之后，你就已经超过了绝大多数 C++ 开发者，面对相同问题时，就更可能快速定位问题。
到这里，我们终于可以展开说一下什么是万能引用。在这之前，需要先引入一个概念叫 引用折叠（reference collapse）。
C++ 中，不允许出现引用的引用，如果你这么写了，编译器会报错。但编译器自己却允许在内部推导时，出现引用的引用，它会将其合并起来，这就是引用折叠。引用折叠的规则是：
T& & => T&，T& && => T& 以及 T&& & => T&；T&& && => T&&；注意，这些都是编译器内的行为，不能写出这种代码。
C++ 中使用引用折叠的场合有 4 个：
接下来我们要使用引用折叠规则了。回到我们的万能引用中，对于一个典型示例：
1 | template <typename T> |
其中 arg 是一个万能引用，所以我们知道，传入 f 的实参是左值还是右值，会被编码到形参类型 T 中。万能引用能做到的是，当实参是一个左值时，T 的结果是一个左值引用，当实参是一个右值时，T 的结果是一个非引用类型（注意和引用折叠做区分，这里并不是一个右值引用，这是模板推导规则之一，可见条款 1）。
我们再将 std::forward 的定义写出来：
1 | template <typename T> |
依次考虑一下。首先，当函数 f 的实参是一个左值时，由于万能引用的推导，f 的模板类型 T 是一个左值引用：
1 | // 推导后： |
对 forward 的实例化结果为：
1 | // 推导后： |
forward 函数实际上什么也没做，返回了一个左值引用。
整体上来看，当给万能引用模板函数 f 传入一个左值时，传递给函数 g 的实参也是一个左值引用，符合完美转发的设定。
考虑第二种情况，当函数 f 的实参是一个右值时，由于万能引用的推导，f 模板类型 T 是一个右值（非引用类型）：
1 | // 推导后： |
对 forward 的实例化结果为：
1 | Widget&& forward(Widget& param) { |
可以看到，forward 将一个左值引用作为输入，返回了一个类型转换后的右值引用。
整体上来看，当给万能引用模板函数 f 传入一个右值时，传递给函数 g 的实参，也是一个右值引用，同样符合完美转发的设定。
最后，对万能引用做一个定义。万能引用并非一种新的引用类型，它其实就是满足以下语境的右值引用：
如果你已经很顺利地看完了前边的内容，那么这一条很容易理解。
C++ 的移动操作并不保证一定会发生移动操作，他仅仅只是把一个类型转换为右值，所以虽然用到了 std::move，移动也不一定总会发生；或者虽然没有显式使用移动语义，但编译器可能会调用移动构造和移动运算符的场景，移动也不总是会发生。
可能的一些原因有：
noexcept，那么移动操作也不会调用；对于其中的第 2 点，展开说一下。移动操作本质上没有什么神奇的，移动比复制快的原因，是因为移动是浅拷贝，也就是只复制了指向数据的指针，而没有复制数据本身。如果一些类型，它的数据本身就是其自身的一部分，比如 std::array，或者小数据量下的 std::vector 和 std::string，当对它们做移动操作时，和复制操作没有效率上的优势。
最后，我们来看一下，完美转发不适用的场景。事实上，大多数使用完美转发的情形都是符合规范的，本条款中提到的一些情况，都是很罕见的用法。
首先来定义一个问题，我们要讨论的示例代码：
1 | template <typename T> |
如果以下两种用法，产生的效果是等价的，那么就可以认为完美转发成功了，否则，完美转发失败了：
1 | g( expression ); // 直接调用内部函数 |
我们来看一下哪些场景不适用完美转发。
在第一章 条款 1 的讨论中，我们将大括号初始化来做模板类型推导时，就发现这种推导是无法执行的，所以，很显然，如果函数 f 传入的是一个大括号初始化，那么就不可能通过编译。
比如，函数 g 的定义为：
1 | void g(const std::vector<int>& v); |
以下代码：
1 | g({1, 2, 3}); // 可以通过编译，编译器隐式转换大括号初始化为 std::vector |
有意思的是，在 条款 2 的讨论中，我们知道，auto 类型是可以接受大括号初始化类型推导的，所以一种变通的修改方案是：
1 | auto temp = {1, 2, 3}; // 先通过 auto 将大括号初始化转换为 std::initializer_list<int> |
读到这里的读者，应该不再会愿意使用 0 和 NULL 来指定空指针了。
1 | f(0); // 预期想推导为 void*，结果推导为 int |
由于函数 f 的形参需要一个万能引用，而常量因为没有地址，无法被引用，所以编译会失败。
在 C++ 中有这样一个规定，如果类的成员函数中，声明了 static const 的成员，由于这样一个成员实际上可以被编译器当作常量来对待，所以编译器不会要求必须给这个成员做定义（只需要做声明）。
而如果这样一个成员变量，没有定义而只有声明，编译器编译不会报错，但对于将他作为 f 的参数绑定到万能引用类型形参，就同样遇到了无法被引用的错误。它会在链接时报错，找不到名称的定义。
修改的方案就是，为它提供定义。
1 | class Widget { |
对于重载函数和模板函数，都存在着没有地方指导万能引用确定引用哪个版本的重载函数或模板实例化的问题，从而导致编译失败。
看下重载函数的例子：
1 | int processVal(int val); |
然后再来看模板函数：
1 | template <typename T> |
调整方案都是一样的，使用一个额外的对象，先为输入的实参做好类型签名，再传递给 f：
1 | int (*)(int) processValPtr = processVal; |
从前边几个情况，可以发现一个普适的规律，万能引用是一种引用，所以它需要绑定的对象，一定是要能找到地址的（可引用的）。位域是另一种无法被直接引用的类型。
1 | struct IP { |
由于位域是由机器字上的若干任意部分组成的，所以无法为其取地址，从而就意味着无法引用。
如果你看到这里，还比较自在，说明你对 C++ 的掌握能力，已经很不错了。有关于万能引用和模板实例化的高级技术，上文中都没有展开，但那些东西是通往高级 C++ 工程师的必经之路，谦虚地说，我还没有完全入门。
如果你到此依然充满热情，那就继续准备开下一章节吧，后半部书中，会讨论一些有不同风味的知识。
本系列的其他文章：
本文同步发布在知乎账号下：https://zhuanlan.zhihu.com/p/1949164417171306465
智能指针是现代 C++ 中的一个重要内容，以至于当使用现代 C++ 编程时，智能指针可以完全取代裸指针。
使用 C 风格裸指针，存在很多已经被人诟病已久的问题，比如：
delete 还是调用某个用于释放资源的函数；delete 还是 delete[]，这都带来了很多风险；为了解决这些问题，现代 C++ 提出了几种智能指针，它的本质是依靠 C++ 的 RAII 设计理念，将资源管理和对象生命周期绑定在一起，从而避免让程序员主动去操作资源释放的行为。unique_ptr 和 shared_ptr 是两种最常见的智能指针，另外还有 weak_ptr 用于解决 shared_ptr 的循环引用问题，在后续内容中会逐个展开讨论。auto_ptr 在 C++11 中被 unique_ptr 取代，所以不要再使用。
当需要使用指针来引用一块资源时，考虑使用智能指针；当需要使用智能指针时，优先考虑 unique_ptr。这里的原则是，大多数情况下，我们分配的资源，是交给“一个”目标使用的，所以专属所有权通常就足够了。
unique_ptr 使用移动语义来实现指针的转移，它没有复制操作，所以才能实现“唯一性”。
它最常见的用处是作为工厂函数的返回值。一个工厂函数，通常是在函数内部创建一个位于堆上的对象，返回之后，需要交接资源的所有权，这就是 unique_ptr 的用武之地。交接之后，资源的责任人变成了调用工厂函数的一方。
unique_ptr 具有自定义析构函数。一个自定义析构函数，是指当智能指针被析构时，选择调用的函数。比如，我们希望在析构智能指针时，打印一些日志，那么就可以使用自定义析构函数。
自定义析构函数可以通过智能指针的第二个模板参数来指定，它可以是函数指针，函数对象或 lambda 表达式等可调用类型，它接受一个参数，类型为原始资源的裸指针。比如：
1 | auto delFunc = [](Object* obj) { |
示例中，使用 lambda 表达式作为智能指针的自定义析构函数。
通常，我们知道，unique_ptr 对象的大小，和裸指针的大小是一样的。不过，当引入智能指针时，问题需要进一步讨论。
当析构器是函数指针时，这个函数指针需要保存在 unique_ptr 的对象内，所以通常 unique_ptr 的大小会增加几个字节（指针大小）；当析构器是函数对象时，析构器对 unique_ptr 空间的影响，则取决于函数对象本身占用的存储空间；当析构器使用 lambda 表达式指定时，因为我们知道，lambda 表达式的本质也是函数对象，对于空捕获列表的 lambda 表达式，不会对 unique_ptr 的空间产生额外需求，但当存在捕获列表时，占用空间则与捕获列表中对象的空间占用相同。
最后，虽然 unique_ptr 可以用来保存一个数组资源，也就是 std::unique_ptr<T[]>，但绝大多数场景下没有这个必要，请使用 vector，array 等线性容器来替代它。
同时，当需要将 unique_ptr 转换为 shared_ptr 时，不要尝试获取它的裸指针后，初始化新的 shared_ptr，这样将很可能带来资源被重复释放的问题。C++ 提供了从 unique_ptr 向 shared_ptr 的类型转换：
1 | // 将工厂函数返回的 unique_ptr 直接转换为 shared_ptr，也是允许的 |
和 unique_ptr 不同，shared_ptr 中需要注意的使用问题更多一些，我们按书中的思路依次展开。
shared_ptr 自身也是指针，但它是共享所有权的智能指针，这意味着多个shared_ptr 可以指向同一块资源，而只有当资源被一个 shared_ptr 指向时，这个 shared_ptr 析构时才负责释放资源。所以，shared_ptr 需要一个计数器，或者严谨点来说，是资源需要一个共享智能指针的计数器。
每个 shared_ptr 的实例由两个指针组成，第一个指针指向负责管理的资源位置，第二个指针指向一个资源控制块。如果有新的 shared_ptr 也指向这个资源，那么它的控制块指针也指向相同的资源控制块。如上提到的计数器就保存在控制块中，另外，控制块中也包括了如自定义的析构器、资源分配器等内容。
虽然 shared_ptr 占用了两个指针的大小，然而它的操作带来的性能开销却远大于 unique_ptr（unique_ptr 和裸指针基本一致）。这由于以下几个原因：
shared_ptr 对象，需要负责分配控制块内存；正因为原子操作计数器的原因，移动构造一个 shared_ptr（计数器不增加），要比复制构造一个 shared_ptr（计数器+1）要更快。
插一句，Rust 中的引用计数，直接提供了两个实现，Rc<T> 和 Arc<T>，分别用于非并发程序下的共享所有权和并发程序下的共享所有权，前者没有使用原子操作实现引用计数，这样就避免了非并发程序时引用计数的性能开销。并发导致的性能损失，应该只有在真正需要时才需要承担。
除此之外，我们还需要注意在使用 shared_ptr 的几个问题。
和 unique_ptr 不同，shared_ptr 的析构器并不是智能指针对象的一部分，因为它保存在控制块中，所以，不会涉及到上一节，不同析构器占用空间的讨论。
1 | auto loggingDel = [](Widget *pw) { |
正因为如此，指向相同资源的不同 shared_ptr 可以在初始化时，接受不同的析构器，然后，只有最后一个 shared_ptr 离开作用域时，会调用当前的析构器。注意，同一个资源，只对应一个析构器，看代码：
1 | auto deleter1 = [](int *p) { delete p; std::cout << "Deleter1\n"; }; |
代码中有两个资源，10 和 20，他们的控制块中，自定义析构器分别指向了 deleter1 和 deleter2，初始化时，计数器的值都为 1。在 a 处，ptr1 被 ptr2 赋值为指向资源 20，那么资源 10 的计数器值为 0，触发资源 10 的析构器 deleter1，而此时资源 20 的计数器值为 2；在 b 处，ptr1 释放，但资源 20 的计数器值变为 1，不用调用资源析构；在 c 处，ptr2 释放，资源 20 的计数器值变为 0，调用资源 20 的析构器 deleter2。
因为 shared_ptr 本身不带有析构器类型，所以即使拥有不同的析构器，它们也可以放在同一个容器中：std::vector<std::shared_ptr<int>> vp {ptr1, ptr2};。
有几种方法可以创建 shared_ptr：
std::make_shared 接口函数。它总会分配一个新的对象，同时创建一个新的控制块，并返回一个新的 shared_ptr，但它不能指定自定义析构器。unique_ptr 出发构造。由于 unique_ptr 并没有控制块，所以使用它创建 shared_ptr 时，编译器会创建一个控制块出来。这个过程，会让 unique_ptr 失去对资源的所有权。shared_ptr 构造函数可以接受一个可调用对象作为自定义析构器，这也是唯一一种可以自定义析构器的方式。对第三种方式展开讨论，它存在一个很容易犯的使用错误，编译器无法报告错误。看以下代码：
1 | auto pw = new Widget; |
我们已经知道，这种创建智能指针的方式，会创建一个控制块，那么，构造 spw1 和 spw2 时，就会分别创建一个控制块，其内部计数器的值均为 1，那么，当 a 处 spw1 释放时，资源 pw 就会被析构掉，而在 b 处，spw2 释放时，就会重复释放资源 pw。
我们应该尽量避免使用这种方式来构造智能指针，除非你真的想利用这里边的灵活性。如果一定要做，那么确保多个析构器中，只有一个析构器会去析构资源，而它作为主析构器，必须在最后被初始化，比如上例中，deleter2 作为主析构器，去析构资源。更合理的建议是，不要用一个裸指针对象去初始化智能指针，而是在初始化智能指针时，同时分配资源：
1 | std::shared_ptr<Widget> spw1(new Widget, deleter2); |
陷阱：如无必要，不要使用裸指针对象来初始化带有自定义析构器的 shared_ptr。
看书中给出的这个示例代码：
1 | std::vector<std::shared_ptr<Widget>> processedWidgets; |
process() 成员函数需要做一个事情，把当前对象以 shared_ptr 方式保存到 processedWidgets 中，最容易想到的实现是：
1 | void Widget::process() { |
结合上一小节的知识，就会意识到这里存在问题，每一个 Widget 实例对象，在 process 之后，都会生成自己的智能指针，并拥有自己的控制块，所以智能指针析构时，这里就会发生重复释放资源的问题！（对象自己的析构函数和智能指针管理资源的析构器都会去析构同一个资源）
C++ 委员会已经意识到这个问题，也为我们提供了解决方案，也就是使用 enable_shared_from_this：
1 | class Widget: public std::enable_shared_from_this<Widget> { |
将 Widget 对象继承自 enable_shared_from_this<Widget> 类型，它会在内部维护一个 weak_ptr 对象（拥有共享所有权但不会重复创建控制块），通过一个成员函数 shared_from_this来使用 weak_ptr 获取 shared_ptr，从而帮我们解决这个问题。
这里还有一个最佳实践，因为 enable_shared_from_this 使用的一个前提是，Widget 需要有一个控制块，也就意味着它需要有一个 shared_ptr 已经指向它（控制块存在），才可以正常调用 shared_from_this，所以，需要避免对象被多种方式管理，比如还在栈上或裸指针指向。
这个最佳实践是实现一个工厂函数，返回 shared_ptr 来管理对象，并禁止调用构造函数：
1 | class Widget: public std::enable_shared_from_this<Widget> { |
工厂函数可以确保对象只能被 shared_ptr 管理，且在调用 process 之前（或者说调用 shared_from_this 之前），一定已经存在一个 shared_ptr 指向它。
技巧：使用 enable_shared_from_this 和对外部隐藏构造函数的方式，来安全地实现在类的成员函数内，获取指向该对象的 shared_ptr。
如果你担心这些 shared_ptr 带来的性能问题和潜在陷阱，那么就应该考虑下代码中是否真的需要共享所有权。如果 unique_ptr 可以完成任务，还是要优先使用 unique_ptr。
从 unique_ptr 创建一个 shared_ptr 很容易，只需要分配一个控制块就行，C++ 已经提供了这种能力。但反过来则不行，我们永远无法将一个 shared_ptr 转变为一个 unique_ptr，即使它的计数器为 1。这也就意味着，如果不有所克制，你的工程中，一定会面临 shared_ptr 泛滥的问题，这意味着代码已经开始变味。
weak_ptr 不是一种新的智能指针，它是一种特殊的 shared_ptr。它使用和 shared_ptr 相同的控制块，所以也拥有两个指针。weak_ptr 使用 shared_ptr 创建：
1 | auto shared_pointer = std::make_shared<int>(); |
weak_ptr 不同于 shared_ptr 的地方在于，它不会影响 shared_ptr 的引用计数。但因为它依然拥有控制块，所以可以利用里边的信息，实现检查智能指针是否悬挂，这是和裸指针所不一样的地方。
因为检查是否悬挂之后，我们通常希望在没有悬挂时操作智能指针，那么“检查”和“操作”分开执行时，在并发程序中就会遇到竞争的问题，所以，它也提供了一种原子性的操作方式：
1 | // 若 weak_pointer 悬挂，shared_pointer == nullptr |
weak_ptr 最常用的地方是解决 shared_ptr 的环形引用导致资源泄漏的问题，想必是学习智能指针一定会接触的问题。书中还提到了另一种 weak_ptr 的用途，即用它来实现检查资源是否失效的需求。
如果我们想设计一个缓存机制，使用容器保存一些智能指针，它们指向一些已分配的资源。如果容器中存储的是 shared_ptr，那么当所有权被转移到外部时，资源就会被析构，如果想要缓存资源而不是直接析构，就用 weak_ptr 所取代，并在必要时，比如重新加载资源到缓存时，通过 weak_ptr 的悬挂检测来决定。
我个人认为不是很常用的做法，也比较取巧，就不列出代码了。
最后提一下，weak_ptr 只是不修改 shared_ptr 的引用计数，但不代表着它没有性能开销，控制块中还有关于 weak_ptr 的计数器，它依然会原子地修改这个计数器。
谬误：weak_ptr 并没有比 shared_ptr 操作效率高。
C++ 有三个 make 函数，它们分别是 std::make_unique，std::make_shared 和 std::allocate_shared，其中，std::make_unique 是在 C++14 中引入的，另外两个是在 C++11 中引入的。
从前边的讨论中我们知道，可以使用 new 来初始化一个智能指针，而不需要考虑 delete 的事情，不过，还是优先推荐使用 make 函数来初始化智能指针。
C++ 中有一种很常见的异常问题，被程序员们广泛讨论，见代码：
1 | // 有一个函数，接受两个参数，一个智能指针，一个值 |
如果，我们通过 new 来初始化智能指针，再调用一个函数来求第二个值，并把这些放在一条语句中，C++ 是允许的：
1 | func(std::shared_ptr<Widget>(new Widget), compute()); |
但这种写法会带来一个异常安全问题。
因为 C++ 并不规定同一个函数参数的参数列表中，各表达式的求值顺序，所以，这个参数列表中，三个操作：new Widget，compute() 和 shared_ptr<Widget>() 将会以随机的方式执行（严谨一些说，new Widget 会在智能指针构造前完成，但 compute() 会在任意位置完成）。如果，compute() 刚好在 new Widget 和智能指针构造之间执行，而它发生了异常，那么，new Widget 的资源便会发生资源泄漏，永远无法被释放。
有几种不同的方案可以避免这个问题：
1 | // 使用 make 函数 |
对于第三种做法，存在一个小问题。因为 ptr 是左值，所以默认按复制传入形参，而复制操作，会让 shared_ptr 的引用计数增加，带来了额外的性能开销。第二种写法，因为第一个实参是右值，按移动传入，不会带来性能开销。第三种方案可以适当改进一下：func(std::move(ptr), compute());。
陷阱：参数列表中多个表达式有存在异常时，将导致手动分配的内存出现内存泄漏，这是 C++ 很常见的一个陷阱。
另一个使用 make 的优点是，它的性能更好。对于 shared_ptr 来说，因为它除了被指向的资源外，还有一块控制块，也位于堆内存中，如果调用 make_shared 操作，那么只需要进行一次内存分配，同时用于资源数据使用和控制块使用。
而如果使用 new 的方式，将先后进行两次内存分配。向操作系统的一次内存申请，其性能将优于两次申请。这同样适用于 std::allocate_shared 操作。
和之前的一些条款一样，使用 make 函数并不是一个完美替代 new 操作来创建智能指针的方案，它也存在一些无法被使用的场景。
第一个场景是自定义析构器。从前边条款中得知，make 函数不能指定自定义析构器，而只能通过 new 关键字来实现：
1 | std::unique_ptr<Widget, decltype(Deleter)> upw(new Widget, Deleter); |
第二个场景是，当希望通过初始化列表作为参数，来调用被指向对象的特殊构造函数时，make 函数会将其按小括号初始化来对待，这在我们之前讨论初始化列表时，也提到过。这里再重复啰嗦一次，见下边代码：
1 | auto ptr = std::make_unique<std::vector<int>>(10, 20); |
这样一条语句，它生成的是一个指向 10 个值为 20 的 vector 的智能指针，还是指向包含 2 个元素，值分别为 10 和 20 的 vector 的智能指针？想必你也比较熟悉，答案是前者。
make 函数做不到通过这一条语句实现后者，这是因为 make 函数内部的实现，在处理对形参的完美转发时，使用的是圆括号，而不是大括号。
如果一定要使用初始化列表来初始化这个资源，可以分开来写：
1 | auto args = {10, 20}; |
第三个场景，前边提到，使用 make 函数可以让对资源内存的分配和对控制块内存的分配，合并在一起申请，从而提高性能，然而，当讨论 weak_ptr 时，这个问题变的复杂。
在控制块中，除了保存引用计数外，还保存着其他信息，比如弱引用计数（注意，weak_ptr 用引用计数来判断自己是否失效，而它构造和析构改变的是弱引用计数）。当引用计数为 0 但弱引用计数不为 0 时（shared_ptr 没有了，但 weak_ptr 还存在一些），我们认为资源应该被释放，这没问题，这里的问题是，如果使用 make 函数统一将资源和控制块分配在一块内存块上，因为弱引用计数还存在，所以控制块不能析构，导致位于同一块内存块的资源内存，也不能被尽早析构（虽然它已经没有用了）。只有当控制块的弱引用计数也为 0 后，整个控制块应该被析构时，操作系统才开始考虑对整个内存块（包括资源内存和控制块内存）进行析构操作。
如果我们的资源内存占用比较大，而 weak_ptr 长时间没有释放，那么这块内存就带来了长期驻留内存的资源占用问题。
使用 new 操作来初始化智能指针，反而可以避免这个问题。虽然这不是一个很急迫的问题，但讨论一下，也是蛮有意思的。技术权衡的正反面，只有了解细节才能在选型时找到最优解。
Pimpl 是 C++ 编程中的一种习惯用法，它全称是 Pointer to implementation。具体来说，比如我们实现一个自定义类型：
1 | // Widget.h |
通常会这么写代码。但这里有一个编译性能的问题。如果我们的 Widget.h 文件没有变，但 Object.h 文件发生了变化，那么对于引用 Widget.h 的用户代码来说，编译时，Widget.h 文件也会被重新编译一遍。当工程代码中间的此类依赖很多很复杂时，编译时间会受到很大的影响。
Pimpl 就可以解决这个问题。它的重构做法是：
Widget.h 头文件中，创建一个类内定义的对象，假设名为 Impl，它的实现放在 Widget.cpp 中。Object 相关的数据都放到 Impl 类型的实现中，而在 Widget.h 的类声明中，只放置一个指向 Impl 对象的指针。1 | // Widget.h |
这样，在 Widget.h 中，就没有了对 Object.h 的引入，从而，修改 Object.cpp 时，引用 Widget.h 头文件的用户代码，就不会再重复编译。
在现代 C++ 中，我们希望能尽可能避免显式使用 new 和 delete 关键字，而是把资源管理交给 RAII 技术。所以很容易想到使用智能指针来替代裸指针。因为 pImpl 是被 Widget 对象独占所有权的，所以使用 unique_ptr 是顺理成章的事情。
1 | // Widget.h |
这个代码看似没问题，并且代码自身编译也没问题，但在调用 Widget 的用户代码那边，编译报错了。报错是，无法找到一个对 Object 的完整实例化。unique_ptr 作为指针，并不需要关心其指向的对象的实例化情况，所以这里看起来很奇怪。
原因是，编译器在为我们创造默认析构函数时，当看到 unique_ptr，会做一个 static_assert，检查 unique_ptr 是否能找到其指向对象的 sizeof 和 delete 运算符定义。这么做是考虑到生成更高效的析构代码。
为了强行解决这个问题，我们可以手动实现析构函数，但只需要生成默认版本的析构函数即可。析构函数放在 Widget.cpp 的末尾，这样，当编译器想要调用析构函数时，一定会先看到 Impl 的定义，也就能知道智能指针指向对象的信息了。另外，因为自定义析构函数后，编译器不会为我们生成默认移动构造函数和移动运算符函数，所以这两个函数也得手动实现一趟，当然，编译器默认生成的复制和移动版本是浅拷贝，就算不是这个原因，大概率也得手动生成一份深拷贝版本。
1 | // Widget.h |
言归正传，虽然 unique_ptr 作为独占所有权指针，用在这里再合适不可，但如果想使用 shared_ptr，就会发现，后者并没有前述的这些问题，这是因为 unique_ptr 的析构器是其类型的一部分，编译器会努力生成最优的代码来让 unique_ptr 做到裸指针的性能，而 shared_ptr 的析构器却不是类型的一部分，所以它不关心析构性能，也就没有在析构时去做完整实例化对象的检查。
智能指针是现代 C++ 中很重要的一部分内容，值得仔细了解。但事实上，编写 demo 时，即使知道裸指针和 unique_ptr 的性能相同，但大多数人还是喜欢先使用裸指针，我仔细想过，唯一的原因可能就是语法差异，语法 * 和写几个单词（auto 和 unique_ptr，make_unique）还是有差距的。
适应新技术需要一个过程，但习惯之后，便会收获便捷和安全。
本系列的其他文章：
本文同步发布在知乎账号下：https://zhuanlan.zhihu.com/p/1943341648118547139
这是一个令很多人头痛的问题，如果没有完全搞懂这里边的门道，是不会愿意使用 C++ 提供的大括号初始化语法的。或者，大多数人多少也有踩过坑的过去。
讨论以下代码：
1 | int x(0); // 使用小括号来初始化 x 值为 0 |
以上这几种写法，本质上有什么区别？这些初始化语法都做到了相同的目的，但作为一个高级语言，这种混乱多变的用法，事实上并不讨喜。于是 C++ 11 引入了统一初始化语法，或者书中被称为大括号初始化语法。
大括号初始化除了能初始化一个单独的值，还可以直接初始化容器：
1 | std::vector<int> v{1, 2, 3}; // 初始化 v 中存放 3 个元素：1，2，3 |
小括号初始化和等号初始化，在一些场合不能使用，但都可以替换成大括号初始化语法，大括号初始化语法适用于所有初始化的场景。
另外，大括号初始化的方式还会禁止不同类型的隐式窄化类型转换，比如，以下代码无法通过编译：
1 | double x, y; |
这避免了一些潜在的精度损失问题。
最后，大括号初始化语法解决了 C++ 的解析语法问题。
讲一下这个问题。解析语法的一个示例为：
1 | Widget w(); |
单纯看这个代码，你（和编译器）都不能判断出 w 到底是一个 Widget 的对象（调用默认构造函数），还是一个返回 Widget 的函数声明。编译器优先会将其解析为一个函数声明，具体要取决于上下文。
大括号初始化语法就直接将两者区分开来了。
1 | Widget w{}; // 一定是初始化 Widget 对象，而不是函数声明 |
然而，好消息总会伴随着坏消息。大括号初始化语法也有一些不适合使用的场景。
一个常见的问题就是它和初始化列表之间的纠葛。
如果一个类型的构造函数中，没有提供任何传入初始化列表作为参数的版本，那么一切都是正常的，但反之，选择调用构造函数时，编译器就会非常强烈地选择使用传入初始化列表作为参数的构造函数版本。如下代码：
1 | class Widget { |
如代码中 w2 的初始化，编译器会强制使用初始化列表作为参数的构造函数，即使它需要额外做将 int 和 bool 转换为 double 的动作。这就是为什么说会 “非常强烈地”。
即使是编译器默认提供的构造函数，比如上例中的默认复制构造函数，也难逃意外。
1 | Widget w0; |
编译器还是会对 w2 调用带有初始化列表作为参数的构造函数，它会将 w0 这个 Widget 类型转换为float，之后转换为 double，最后使用那个敏感的版本来构造 w2。
那么，在上边这些问题之后，以下代码声明，调用的是什么构造函数呢？
1 | Widget w1; // 调用无参构造函数 |
上边的内容可能比较太 “语言律师” 了，但它在实际工程中，确确实实会带来一些潜在的意外。比如：
1 | std::vector<int> v1(10, 20); // 调用了 vector 的一个构造函数，创建了包含有 10 个元素，元素值都是 20 的 vector 对象 |
事实上我就在这里犯过错。
作为类的实现者，最好能避免用户犯这种错误，让用户使用类型时，不用在意它应该怎么写，才能调用到哪个构造函数。C++ STL 中的这种设计，事实上是个败笔，当然，根源还是 C++ 语法的问题。
陷阱：区分一个类型使用小括号来传入多个值，和用大括号来传入多个值的区别，尤其是标准库类型。
事实上，在工程实践中，很难快速意识到这种问题，比如说，最一开始的实现中，没有添加带有初始化列表的构造函数，之后也在很远的地方，正常使用大括号初始化语法来初始化类的对象（它会调用到构造函数），很久之后，我们又需要给类中添加带有初始化列表的构造函数版本，添加之后，发现测试用例挂了（感谢你提前编写了测试用例吧）。
陷阱：在为自定义类添加带有初始化列表作为参数的构造函数时，一定要小心。
现在，关于现代 C++ 中，是否建议使用大括号语法来初始化对象，依然是激烈争论的议题。两者各有优缺点。对于我们，最重要的是，理解上述的这些问题，并在使用大括号初始化语法和带有初始化列表的构造函数时，多留个心眼。
对于模板的实现者来说，这个问题更为头疼，因为模板的实现者无法决定用户会使用小括号还是大括号，从而便无法决定模板中的两种不同实例化，应该怎么做到统一实现。
一条耳熟能详的 C++11 建议，使用 nullptr 替代 NULL 或 0 来作为空指针类型。
原因是 0 可能被解析为 int，而 NULL 在大多数库中的实现也只是宏定义到 0。nullptr 不具备整形类型，当然，它也不是某一种类型的指针，它的类型是 std::nullptr_t，它的能力是提供了可以转换为任意指针类型的类型转换操作。
这一条没有什么副作用，所以大多数程序员都已经无缝切换。
C++ 11 标准中另一个实用的改进，允许我们使用 using 关键字来声明一些自定义类型，也就是类型别名，替代传统 C/C++ 中的 typedef 语法。
替换并不只是让代码更清晰，毕竟并没有那么多场合需要声明很复杂的类型别名，但有一些是 typedef 做不到的。
一个例子是类型别名可以模板化。举例来说：
1 | // 这是一个存放多个类型及类型带有的自定义分配器的列表 |
如果使用 typedef，因为不能声明模板别名，只能编写一个自定义结构：
1 | template<typename T> |
编写的代码就要复杂一些，应用代码 b 中的用法，typename 不能省略，因为编译器需要知道后边的 MyAllocList<T>::type 是一个类型，而不是其他什么东西（因为从语法上来看，它仅仅只是对一个模板类内静态成员的引用）。
也许你会认为，这种场景太少见了，然而，在库实现中，这种用法却到处都是，C++ 11 中的类型特征，就是采用这种原始的方式实现的，你会在各种地方看到诸如 std::remove_const<T>::type 这种以 ::type 结尾的类型修饰词转换操作。如果这些场景下的应用代码都使用 typedef，那么将提高代码的复杂性。
当然，在 C++11 的库实现中，还是大量使用了 typedef 这种用法来定义类型特征，书中没有解释原因，不过，using 的好处在未来被人重视起来，C++14 开始，都添加了对应的类型别名版本，比如：
1 | std::remove_const<T>::type // C++11 中将 const T 类型转换为 T |
作者建议，无条件地优先使用 using，即使你使用的是 C++11，也去自己实现用类型别名来取代 typedef 实现类型特征：
1 | template <typename T> using remove_const_t = typename remove_const<T>::type; |
C++ 11 中的另一个新引入的语法特征，使用枚举类来取代枚举。在绝大多数场景下，你都应该这样做。下文把 enum 定义的类型叫做枚举，把 enum class 定义的类型叫做枚举类。
我们知道，枚举是不限定作用域的，也就是说，通过枚举定义的类型，其作用域与定义枚举的作用域一致，而不是限定在枚举类型本身，这导致枚举类型的名字污染以及潜在的类型转换错误。而枚举类可以做到这一点。这带来很多好处，我相信不需要把书里的例子拿出来复述一遍了。
另外一个好处是，枚举类可以做前置声明（在表面上看）：
1 | enum Color; // 预先前置声明枚举，后边再定义，编译会出错 |
究其原因，并不是语法上不允许，而是编译器需要在前置声明时，为枚举（或枚举类）选择一个默认的底层实现类型，而枚举没有默认的底层实现类型，所以编译器无法预先分配前置声明的类型。
所以，在 Pre-C++ 11，也可以通过手动指定枚举类型来实现将枚举做前置声明：
1 | enum Color: std::uint8_t; |
枚举类不需要手动指定，就可以前置声明，因为枚举类有默认的底层实现类型：int。所以，这个好处是在不需要指定底层类型时，做前置声明。
书中提到了一个枚举可能的用途。因为枚举可以做隐式类型转换，而枚举类不可以，所以在一些明确需要编译器完成隐式类型转换的场合，枚举就有用了。比如说 std::tuple 下的 std::get<> 操作，后者会按指定的静态下标来获取元组中的元素。
考虑以下代码：
1 | using UserInfo = std::tuple<std::string, std::string, std::size_t>; |
但这种写法，从调用方来看，很难直观地看到获取的 val 是什么东西。
所以我们习惯用枚举来作为下标，因为枚举定义的默认值是从 0 开始的整形，刚好可以用来做下标值：
1 | enum UserInfoFields { uiName, uiEmail, uiReputation }; |
然而，如果使用的是枚举类，则代码会冗长一些：
1 | enum class UserInfoFields { uiName, uiEmail, uiReputation }; |
其他办法也不会比它更简单。
当然，在我看来，这个遗留问题，更应该拷问下，是不是 std::get<> 的设计有问题，如果 C++ 可以提供 info.uiEmail 这种更便捷的语法，这里的问题便不攻自破了。
在 C++11 之前，如果我们需要删除类内的一些类成员函数，比如编译器自动生成的那些构造函数，做法是将这些函数显式声明出来，并放在 private 区中，同时不去实现它。
这样，如果类外部的对象调用这些被删除的函数，则编译器会因为这些函数位于 private 而阻止调用，如果类内调用这些被删除的函数，则编译器会因为这些函数没有被定义而报错。
在 C++11 中，无条件将这种做法替换为使用 delete 关键字来标记，也就是在类成员函数声明的末尾添加 = delete; 语法。编译器会保证这些函数不允许被实现和调用。
delete 的第一个优点便是简单，比之前的做法少写一点代码。但其另外一个无法被取代的优点是，它可以用来修饰一个普通函数（类外定义的函数）。举例来说：
1 | // 我们有一个函数 |
如果我们不允许一些特殊的类型转换，就需要利用 delete 来删除一些 “重载版本”：
1 | bool isLucky(char) = delete; |
另外，delete 还可以删除那些不希望被模板实例化的模板类型：
1 | template<typename T> void processPointer(T* ptr); |
值得一提的是，如果模板函数是类内的成员函数，则无法通过改到 private 中来删除实例化，只能通过 delete 来删除。所以，private 的方案也并不总是能应用在类内成员函数的删除。
首先需要明确函数的 改写 和 重载 的区别。重载可以实现多个函数名称相同，但函数参数类型不同的一系列函数，从而方便调用使用；而改写是派生类对象中，实现和基类中 相同 的虚函数，从而可以让多态行为生效（有时也叫做 覆写 或 重写）。
上文中我高亮了 相同 两个字，在 C++ 标准中，需要满足一定的约束，才能实现改写的目的。
在 C++98 中，已经提出的约束有：
在 C++11 中，新增了一条：
陷阱：C++11 中，需要改写的成员函数，需要保证具有相同的引用性质。
有关于引用修饰词，书中也在该小节予以大篇幅的介绍。引用修饰词是对成员函数的修饰，来标记该成员函数应该在对象是左值引用还是右值引用时被调用，因为有些场景中，我们希望调用左值引用对象的成员函数与调用右值引用对象的成员函数时，采用不同的实现策略。
我个人认为这部分内容和条款本身没有直接联系，所以不再做展开。
回到条款中，如果希望改写类成员函数，则无条件建议在派生类中，对要改写的函数使用 override 来修饰。编译器会对这种修饰词做检查，排查出任何与成员函数改写相关的意外、漏写或设计错误。
另外，C++11 还提供了另一个关键字 final，和 override 刚好相反，被修饰为 final 的成员函数，将拒绝被其后边继承的派生类中改写。推荐在编写类层次结构时，总是留意去使用这两个关键字，它们可能会帮你大忙。
const_iterator 用于指定指向带有 const 属性的 iterator 类型，所以它所指向的值，内容不可修改。建议在可能的情况下，使用 const_iterator 代替 iterator。
C++98 中 const_iterator 的实现不完整，所以若想在 C++98 中使用，需要做一些额外的约束。C++ 98 中没有提供 cbegin() 和 cend() 等操作，所以需要这样使用：
1 | std::vector<int> values; |
不需要特别了解这种用法，现在使用 C++98 的场合并不多了，即使有那种环境，使用迭代器而不是指针的场合就更少了。
在 C++11 中，标准的写法变成了调用 values.cbegin() 和 values.cend()，不需要我多举例子了。
讨论另一个话题。现代 C++ 中，除了为大多数标准库容器提供 cbegin() 和 cend() 接口之外，还提供了非成员函数版本的 cbegin() 和 cend()，那么，什么时候使用成员函数版本，什么时候使用非成员函数版本？或者说，非成员函数版本的意义是什么？
答案是，在一些容器中，或类似容器的数据结构，如数组中，是没有成员函数版本的迭代器获取接口的，如果在泛型的实现中，调用成员函数版本的迭代器获取，便会导致编译错误，而使用非成员函数的版本，则可以充分兼容这种情况。
举例来说：
1 | // 我们实现一个泛型的容器操作，可以接受各种不同的容器类型 |
很明显可以看出来，如果容器 C 没有内置的成员函数版本 cbegin() 和 cend()，这个实现也是可以工作的。
谬误：非成员函数版本的 cbegin() 和 cend() 与成员函数版本的 cbegin() 和 cend()，在大多数情况下都一样，但建议在可能的情况下，还是使用非成员函数版本。
陷阱：不过需要注意，非成员函数版本的 cbegin() 和 cend() 在 C++14 中才提供，而在 C++11 中不存在。所以，将你的项目中构建参数里用 --std=c++14 代替 --std=c++11 吧。
如果你的项目中不得不使用 C++11，那么实现一个非成员函数版本的 cbegin 也非常方便：
1 | template<typename C> |
实现方案非常取巧，直觉上，在实现体中，应该会写成：return container.cbegin();，但因为有一些容器，它并没有成员函数版本的 cbegin()，所以这样不可行。上边的实现策略，依据是：如果非成员函数版本的 begin() 中传入的是一个 const 类型容器，那么它返回的是 const_iterator，所以这个实现的重点在模板函数的参数声明上。这种实现，对数组也一样适用。
这一条聊一下异常，C++ 中，异常的使用这部分话题，是高频被讨论到的话题。然而本条款更关注的是，如果在使用异常时，让编译器尽可能简化对异常代码的处理。
在实现接口函数时，如果明知道一个函数不会抛出异常，但没有使用 noexcept 声明，那这就是接口设计缺陷。使用 noexcept，可以让函数以及调用函数的其他函数，能够生成更好的代码。
在 C++11 之前，我们使用 throw() 来修饰一个函数会抛出异常，但这种修饰，编译器能做的优化并不多，所以不建议再使用。
使用 noexcept 修饰后，编译器就会做一些更激进的优化。讨论一个复杂的例子。C++11 中的移动语义，由于需要考虑异常，所以，只有在被 noexcept 修饰后，才会说明移动的过程不会发生异常（也就是说，不会因为中途出现异常，导致了数据被破坏），编译器才能妥善放心地使用移动操作。
swap() 函数是 C++ 标准库中一个很常见的操作，然而，它有多种不同的实现，最容易理解的就是，我们是应该采用复制操作来交换数据，还是用移动操作来交换数据，移动操作显然更高效，但其前提便是，swap(a, b) 中的两个输入，都必须是 noexcept 的。
一个典型的 swap 函数声明为：
1 | void swap(pair &p) noexcept(noexcept(swap(first, p.first)) && noexcept(swap(second, p.second))); |
末尾的声明称为 条件式 noexcept 声明，满足 swap 是否可以为 noexcept 的前提是，传入的每个输入，都必须是 noexcept 的。
所以可以看得出来，如果想保证函数调用时，尽可能会通过 noexcept 修饰，就必须让其相关函数都是 noexcept 的。
然而，大多数函数其实是中立的，虽然自身不抛出异常，但其内部调用的函数（和更深的调用层次中的函数），可能会抛出异常，所以它也不能使用 noexcept 修饰。
当然，也不能刻意为了 noexcept 而扭曲了函数实现，那就是主次不分了。如果已经为接口函数添加了 noexcept 修饰，但是在将来又删除这个修饰，那么很有可能，在很多调用该函数的其他场景中，造成很多编译错误。
在 C++11 中，所有的析构函数是默认带有 noexcept 属性的，不需要手动添加。
C++11 中引入了一个新的关键字 constexpr，它和 const 的区别用一句话就可以清晰的说明。const 是表示对象的不可变性（后续无法修改该对象），constexpr 是表示对象的常量性（编译期便可求值）。过去，我们对 const 等价于 常量 的错误观念，应该被纠正。
谬误：const 表示的是不可变性，其反义词是 mutable，并不表示常量。constexpr 才表示常量。至于关键字的取名，属于 C++ 特色了，取名总是很难与其实际意义相契合。
所以，constexpr 的对象，一定是 const 的（常量是不可变的），但反过来不成立（不可变的变量可能是受约束的变量）。
由于 constexpr 修饰的是常量，所以编译器可以在编译期对这种对象做求值，体现出来的便是，会把运行时的一些开销，移动到编译时完成。
如果使用 constexpr 修饰函数，并不意味着这个函数一定可以在编译期求值，它只是表示，当函数的参数都是常量时，编译器才会对这个函数做编译期求值，否则则和正常函数没有区别。
谬误：使用 constexpr 修饰的函数，只有当其参数都是常量时，才会做编译期求值。
在 C++11 中，constexpr 修饰函数还有一些受限，比如只能有一个 return，也不能存在条件语句，这是为了让编译期能更好的完成求值计算。不过，在 C++14 中，这种没必要的约束被解除了。所以，有条件时，尽量用 C++14 代替 C++11。
constexpr 修饰类如果用 constexpr 修饰了类的构造函数，那么很可能会让类定义的对象，也成为一个常量。这很神奇，但确实存在，如书中示例：
1 | class Point { |
因为它是常量对象，所以也可以用在任何使用 constexpr 修饰的常量函数中：
1 | constexpr Point midPoint(const Point &p1, const Point &p2) noexcept { |
这意味着，mid 这个对象，其构造过程涉及到了构造函数，访问器，以及非成员函数的调用，但它依然是一个常量，可以放在只读内存中。
不过，如果类中的成员函数修改了对象的成员数据，则在 C++11 中，不能修饰为 constepxr，因为我们理应认为，这种函数没有不可变性。不过，在 C++14 中，这种约束也被去掉了。所以，在 C++14 中，可以编写：
1 | class Point { |
使用 constexpr 没有副作用，所以在可以使用它的时候，还是尽量去使用它。但如果你是在编写接口函数，在添加 constexpr 修饰时，一定想清楚，不要在将来又想要删除它，那时候，可能和 noexcept 一样，会遇到很多编译错误。
从条款标题上看，似乎 const 修饰的成员函数，应该不可能存在线程安全性，因为 const 修饰后，它们是只读操作，不会对外部数据产生修改和破坏性的影响。
然而，C++ 还提供了 mutable 这个关键字，它自相矛盾地设计了这样一种机制：在类的 const 成员函数中，允许修改被 mutable 修饰的成员变量。比如：
1 | class Widget { |
看起来很不合理，对吧？
因为这个机制，所以 const 成员函数，并不完全可以认为是只读的，从而，在这种场合下，如果这个成员函数刚好位于多线程上下文中，就很有可能出现常见的并发问题，就如同那些普通的并发场景下的问题一样的问题。
陷阱：const 成员函数，不一定是完全不会对外界产生影响的函数。留意那些 mutable 修饰的成员变量。
解决方案，书中列举了很多，但我认为没必要展开，因为它脱离了本条款的重点，加锁、原子操作等常见的方案都可以处理，只要把那个看起来是 const 的成员函数，当作普通函数处理就好了。
mutable 很早就有了，事实上它不比 const 来的更晚。这种设计的场合，通常发生在对接口函数的维护中。
假设你有一个已经公开的接口类，其中的 const 成员函数接口已经被很多地方引用，如果此时，因为一些与 const 本身要保护的主体不太相关的需求，需要破坏该接口的 const 属性，应该怎么办？使用 mutable 便是一个办法。
举个具体的例子，如果有一个控制数据库的类，其中有一个 const 成员函数是查询数据库信息。但现在有一个新需求，要求在每次查询数据库信息时，将查询日志写入一个位置，在不删除 const 属性的前提下，一种解决办法，便是把日志存放对象修饰为 mutable，这样就可以在 const 成员函数中写入日志了。写入日志本身是非 const 的操作，但它不违背这个成员函数添加 const 的初衷，即保证该函数不会改变数据库数据。
所以，在这些场合下，如果引入多线程，便可能产生奇怪的问题，这些问题非常难定位。这就是这一条款要表达的内容。
特殊成员函数包括默认构造函数、析构函数、复制构造函数和复制赋值运算符函数，在 C++11 之后，又增加了移动构造函数和移动赋值运算符函数。编译器可能为一些类自动生成其中部分或全部特殊成员函数。本条规则需要留意，它们的隐式行为可能导致程序错误或性能衰退。
编译器隐式生成特殊构造函数的规则是：
virtual 的，那么此时生成的析构函数，也是 virtual 的。C++11 引入了 noexcept 关键字，生成的析构函数也默认带有 noexcept 属性。C++ 本有意将两者统一起来，避免上述加粗内容的歧义，但考虑到代码兼容的问题，此条只能成为建议，而不是规则。书中称为 “大三律（Rule of Three）”：如果类中声明了复制构造函数、复制赋值运算符或析构函数中的任何一个，就应该同时声明这三个。
陷阱：复制构造函数和复制赋值运算符的隐式生成是独立的；移动构造函数和移动赋值运算符的隐式生成是互斥的。
建议：大三律规则，如果类中声明了复制构造函数、复制赋值运算符或析构函数中的任何一个，那么就应该同时声明这三个。
大三律的理由是，如果一个类中涉及到了这三种特殊成员函数中的任何一个，说明这个类会做资源管理，如果它会做资源管理，那么这三个就应该同时存在。进一步地，如果用户自定义了这三个之中任何一个成员函数，那么其他成员函数就也应该交由用户自定义，而不是自动生成，但 C++98 中没有对此做约束。
在 C++11 中，成功让大三律能自动推广到移动操作，使之成为规则而不仅仅是建议，即其中之一存在自定义版本时，就不会自动生成其他几个成员函数。
需要留意，移动构造函数和移动赋值运算符函数，不一定真的会让对象以移动的方式构造或赋值，能否移动取决于这个对象的所有组成部分是否可以移动。如果不能，移动构造函数和移动赋值运算符函数会转而以复制的方式来执行。
原理上来说，它们使用了 std::move() 操作，而这个操作，实际做的只是尝试性把左值引用类型转换为右值引用。第五章的条款会展开这个话题。
使用 =default 可以强行让编译器生成默认特殊成员函数，这样将隐式生成改为显式生成，让代码更容易理解，也可以避免意外地隐式生成规则生效或失效导致的一系列问题。
比如说下边的示例：
1 | class StringTable { |
如果我们在未来的某一天，或者是其他开发人员，对此代码做了一些修改。比如想要在资源申请和释放时，添加日志记录，这需求非常常见。为了释放时记录日志，我们不得不自定义析构函数，但我们忘记了大三律规则：
1 | class StringTable { |
这种改动似乎合理，但却引入了很严重的性能问题。添加自定义析构函数后，会阻止移动操作的隐式生成，但不会阻止复制操作的隐式生成。所以，第一个版本中，对象可以通过移动操作来高效移动，但添加日志后，我们发现对象只能用复制操作了，因为负载很大，所以引入了严重的性能下降。
是不是很 amazing 呀！一个简单的改进：
1 | class StringTable { |
C++ 的进化和 C++ 工程师的成长，就是在这样一遍又一遍的摸索和爬坑的过程中完成的。
本系列的其他文章：
本文同步发布在知乎账号下：https://zhuanlan.zhihu.com/p/1939768367813727100
人的一生可以划分成多个不同的阶段，每个阶段有不同的任务、目标和心境。我试着按每 9 年一个阶段来划分，有这样一个总结（末尾引号中一句话是对这个阶段的赠语）。
0 到 9 岁：完全依赖他人生活，好奇心旺盛，学习生存技能，认识世界，满足作为一个人的基本能力。”世界是一本打开的书，每一天都是新的一页“
9 到 18 岁：开始形成自我认知，开始学习专业能力，掌握和传承那些前辈留下的知识，渴望独立但又依赖他人。”现在的困惑是未来智慧的种子“
18 到 27 岁：自由地规划自己的人生目标，坚实基础，追求真理，探索自己，尝试开始反哺社会，充满希望，也常感焦虑。”勇敢不是不害怕，而是害怕时仍毅然前行“
27 到 36 岁：找到同路人一起前行，养育孩子，事业家庭双重责任，理想和现实冲突不断。”比较是偷走幸福的元凶，走出自己的节奏“
36 到 45 岁：重新认识世界，理解很多过去的事情，与自己和解，事业小有所成或寻找新的机会，压抑但坚韧。”照顾好别人之前，先照顾好自己“
45 到 54 岁：对生活的期待发生变化，子女独立，父母年迈，心态回归家庭，培养更稳定更包容的情绪。”人生可以从不同的地方多次闪光，不要太早放弃“
54 到 63 岁：体力下降但心智更成熟，从给社会创造财富的岗位上退出，就像曾经年轻的自己，再次寻找自己人生的新目标。”接受变化，接受新思想，永远保持好奇心“
63 到 72 岁：开始抵抗疾病的侵袭，自己过去固有的生活习惯和观念受到冲击，更努力的适应新环境。“乐于改变的人找到了自己新的生活目标”
72 到 81 岁：认识的人逐渐离开自己，对人的一生有了新的看法，并尽可能把这些东西留下来，积极面对未来。“时光会带走很多，但不会带有爱和记忆”
81 到 90 岁：依赖他人照顾生活，但精神上却高度自由，将自己的经历留给后人，指导晚辈成长。“你人生中写下的每一个标点，都有其意义”
虽然这只是人生的几个阶段，但如果将它们看作是不同次的生命，我们就会更加珍惜眼前的生活，理解自己。试着去体验不同的人生，扮演不同的角色，经历各具特色的故事。
封面图片来自豆包 AI。
转载自我自己的微信公众号，欢迎关注。