基本信息
阅读时间：约 24 分钟
字数：约 9667 字
摘要：文本扩展的下一层不是更多模板，而是语法：变量与默认值、光标停靠点、日期时间计算、剪贴板与上下文占位符。本篇给出 VDCF 四层模型、静态与半自动片段的能力对比、四项度量指标和两周落地清单。
全文语音
中文
English
日本語
한국어
静态片段的天花板：一份模板复制三次，就是崩塌的起点
晚上九点四十，深圳南山一间还亮着灯的办公室里，陈默的键盘右侧放着半杯凉透的美式。他把光标停在客户的回复框里，敲下四个字符，屏幕上跳出一段两百一十七字的退款说明。接着他删掉其中六处表述，改了三个数字，又补了一句道歉——原本应该三秒完成的事，最后花了他一分二十秒。陈默三十六岁，是一家跨境家居品牌的售后主管，手下九个人，每天要处理三百多封邮件和四百多条站内消息。
"我那时候以为是自己模板写得不够全，"陈默说，"后来才明白，问题不在模板，在模板里没有语法。"
所谓静态片段，就是一段被触发词唤出的固定文本。它的能力边界很清晰：只能替换固定串。一旦文本里出现会变化的东西——订单尾号、退款金额、承诺日期、客户称呼、物流状态——它就无能为力，唯一的应对方式是复制一份改一改。三个变量、每个变量三种取值，理论上就是九份模板；这还只是乘法，不是加法。
陈默的退款场景很典型：按物流状态分「未发货」「已发货未签收」「已签收」，再按是否工作日分两套时效承诺，排列组合是六份。但他的库里实际躺着十一份，其中四份是三年前的老时效，没人敢删——因为没人知道哪份还在被谁引用。这就是静态片段真正的代价：不是写的时候慢，是三个月后你不敢动它。
本篇和市面上大多数讲文本扩展的文章不是一个角度。我们不打算再算一遍"把两百次敲打压缩成两个字母省了多少分钟"，那笔账在上一篇已经算过了。这里要讲的是语法层：变量、光标停靠点、日期与时间计算、剪贴板与上下文占位符。这四类能力决定的是一个片段能覆盖多少种场景，而不是你库里有多少条片段。
一句话概括本篇主张：静态片段是常量，带变量的片段是函数，带日期计算和上下文的片段是有外部输入的函数。当你用"程序库"而不是"文本库"的眼光看待它，命名、默认值、依赖和备份就都变成了必须回答的问题。
语法层四层模型：变量、停靠点、日期计算与上下文
先把全文的结构给出来。我把文本扩展的语法能力分成四层，取名 VDCF：V 是变量（Variable），D 是光标停靠点（Dock），C 是日期与时间计算（Calendar），F 是上下文与剪贴板（Field-Context）。这四层不是并列的功能清单，而是层层叠加的覆盖力——每加一层，同一条片段能吃的场景就扩大一圈。
换个说法更好懂：静态片段相当于常量，加了变量相当于函数，加了日期计算相当于能读取系统时钟的函数，加了上下文相当于能感知当前环境的函数。这个比喻不是修辞，它直接决定了后面所有工程决策——既然是程序库，就要讲命名、讲默认值、讲依赖深度、讲版本。
覆盖力的差别有多大？我们对陈默小组三十天的输入日志做了一次清点，得到一组示意数据：库里四十六条纯静态片段，覆盖了全部重复串的百分之三十一；把其中二十条改造成带变量的形式，同样四十六条，覆盖率升到百分之五十八；再给它们加上日期计算和上下文占位符，覆盖率升到百分之七十九。片段总数一次都没变过。
这里的覆盖率需要一个明确定义，否则没法度量：覆盖率等于「由片段承载的字符数」除以「日志中全部重复串的字符数」。重复串的判定口径是「三十天内出现过三次及以上、长度不小于十二个字符的连续文本」。口径要先定死，不然每次算出来的数都对不上。
作为参照基线，公开研究常见的量级显示，成年人的英文打字速度约每分钟四十个词，中文输入约每分钟三十到四十字。按这个量级，一段两百字的话术手打大约要五到六分钟。但我们反复强调：这个基线只是让你对"规模"有概念，本篇的度量口径是覆盖率与维护成本，不是省了多少分钟。
理解四层模型还有个实用价值——它能帮你判断"我该先做哪一步"。如果你的库里还全是静态片段，先做变量，收益最大、风险最小；如果变量已经铺开了，再做日期计算；上下文和剪贴板放最后，因为它依赖你对工具能力的了解，也最容易出现空值问题。
变量：命名、默认值与嵌套替换
变量在不同工具里有三种形态。第一种是触发时弹窗填写，典型是 TextExpander 的 fill-in 字段，展开后弹出一个表单让你逐项填；第二种是位置参数，典型是 VS Code 用户片段里的 $1、$2，靠 Tab 键顺序跳转；第三种是带默认值的命名变量，写法类似 ${客户称呼:您好}，不填就用默认值。三种形态不冲突，成熟的片段常常混用。
默认值是被严重低估的设计。写 ${客户称呼} 还是 ${客户称呼:您好}，差别不是少打两个字，而是把片段从"必须填完才能用"变成"可以先填六成就发出去"。陈默的做法是：默认值一律写上一版真实出现过的值，而不是写"请填写"这类占位提示——因为后者的语义是"这里必须改"，前者是"这里通常就这样"，心理负担完全不同。
嵌套替换是变量层的进阶用法：变量的值里可以再套变量。比如 ${承诺时效} 这个变量，它自己的值里含有 ${发货日} 和 ${工作日偏移}，展开时先解内层再解外层。这条能力是后面第七章"片段调用片段"的基础——当变量的值可以来自另一条片段的输出，片段库才真正有了单一数据源。
命名规则建议很朴素：名词在前、限定在后。用「客户姓」「订单尾号」「承诺时效」，不要用 a1、x、p2 这类短名。理由不是美观，是三个月后你必须在不展开片段的情况下，从名字判断出它会插在哪里。一个可操作的判据：名字里至少要有一个能在原文中被肉眼找到的词。
变量数量要有上限。陈默给每条片段设的上限是五个变量，这是踩坑踩出来的：示意数据显示，当一条片段的变量超过五个，他小组的填写完成率从百分之九十二掉到百分之五十四，三十天自检记录里，变量最多的那三条片段贡献了全部撤销操作的三分之一。
"变量不是越多越好，"陈默说，"我后来把一条七个变量的片段拆成了两条三条变量的，撤销次数当周就少了六成。人的注意力就那么几个格子，你塞七个空给他，他就干脆不用了。"这背后其实对应一个公开研究常被提到的量级：人的短时记忆容量大约是七加减二个组块，但那是理论上限，实际工作中能稳定保持的通常更少。
光标停靠点：让填表动线变成一条直线
停靠点（tabstop）是变量层的搭档。在 VS Code 的片段语法里，$1、$2 是顺序跳转的停靠位，$0 是最终停靠位——也就是你填完所有内容后光标最后停下的地方。${1:默认} 则是带默认值的停靠位，光标落上去时默认值处于选中状态，直接输入就覆盖，不输入按 Tab 就跳过。
镜像停靠点是另一个实用特性：同一个编号在片段里出现多次时，它们会被同时编辑。比如在报价片段里，客户名出现在开头的称呼和结尾的落款两处，都标成 $1，你填一次，两处同步变。这个特性能消灭一类很难发现的低级错误——改了开头忘了改结尾。
动线设计有一条容易被忽略的原则：停靠点的编号顺序应该按"人填写的顺序"排，而不是按"文本出现的顺序"排。这是最常见的错误。举个例子，一段售后回复里，金额在第三段，客户名在第一段，但人实际的填写顺序是先查客户名、再查金额、最后补签名——那么正确的编号就是客户名 $1、金额 $2、签名 $3，即使金额在文本里出现得更靠后。
陈默的合同片段改造是个具体例子。改造前，他要把六处手写位置逐个找出来改：客户名、合同号、金额大写、金额小写、签署日期、签名位。改造后，客户名是 $1，金额大小写共用 $2（镜像），签署日期由日期计算自动填，合同号带默认值，最后光标停在 $0 签名位。六处手工位置压成了三个停靠点。
示意数据显示，这个片段的平均填写时长从四十八秒降到十九秒，用的是小组三十天内的自检计时记录，不是精确实验，只能作为量级参考。真正的收益其实不在速度，而在"漏改"—改造后该片段的漏改工单从每月五单降到零。
还有一条工程约定值得抄：把 $0 永远留给"最后要人工确认的位置"。签名位、落款日期位、需要人复核的金额位。这样每填完一条片段，光标都停在一个需要你点一下头的地方，形成天然的复核环节。
日期与时间计算：从「今天」到「第三个工作日」
日期计算是四层里收益最直观、也最容易埋雷的一层。基础能力是格式化输出：YYYY-MM-DD、YYYY 年 M 月 D 日、斜杠格式、带星期的格式。麻烦在于各工具的"格式方言"不一样——TextExpander 走的是类 strftime 的百分号写法，Raycast 用花括号占位符配格式串，Espanso 通过 date 扩展加 format 参数。上手第一件事不是写片段，是查清楚你手上这个工具的格式串怎么写。
实际用得最多的计算只有四类：今天、N 天之后、上个月最后一天、工作日偏移。前三类多数工具原生支持，第四类多数工具不支持，需要绕路。下面逐个说清边界。
相对偏移的写法大同小异：加七天、减一个月、加一年这类表达在各工具里都有对应语法。真正的坑在边界日期。一月三十一日减一个月，有的工具给十二月三十一日，有的给十二月一日——两种行为都能在文档里找到依据，因为"上月同日"本身就没有唯一定义。凡是涉及对客承诺的时效，这类边界必须先手动验证过再上线。
求某个月的最后一天，通用思路是"先跳到下个月同日，再减一天"。这个思路在大多数月份都成立，但在一月三十一日这样的日期上会出问题：跳到二月三十一日，工具可能解析成三月三日，减一天得到三月二日，完全不是你要的二月二十八日。稳妥做法是改用"下个月第一天的上月最后一天"这类显式表达，或者干脆维护一张月末日期表片段，按月份取值。
工作日偏移是最需要谨慎的一项。多数工具没有内建"第 N 个工作日"的概念，两条路可选：一是通过 shell 扩展调用系统的日期命令自己算，自动化程度高但依赖环境；二是维护一份节假日清单片段，让人工确认一次。陈默选的是第二条，理由很实在：对客承诺算错一天，成本远高于让人多点一次确认。
数字锚点在这里很硬：把"四十八小时内"这类固定承诺改成变量加日期计算之后，示意数据显示时效算错的工单从每月七单降到一单。剩下那一单发生在二月底——正好卡在闰年边界上。这也说明一件事：日期计算片段必须有一份边界用例清单，在月末、跨年、闰年、跨夏令时这四种情况下各验证一次。
还有一条容易被忽视的写法约定：日期变量建议统一带上格式默认值，并且把格式写在变量名里，比如 ${承诺日期:YYYY-MM-DD}。这样在片段源码里一眼能看出它会输出什么，省掉"展开一下看看"的时间。
剪贴板与上下文占位符：让片段知道「现在在哪」
剪贴板占位符是最容易上手的一类能力。它的语义很简单：展开片段时，把当前剪贴板的内容插到指定位置。典型用法是复制订单号后触发一条查询模板，订单号自动落在查询串里。Raycast 和 Alfred 的片段都提供了这类占位符，Espanso 则通过 clipboard 扩展实现。
第二类用法是"选中文本包夹"。它的操作范式和"插入新文本"完全不同：你先选中一段已有文本，再触发片段，被选中的文本会被放进片段内部的指定位置。VS Code 里对应的是 TM_SELECTED_TEXT，常见用法是选中一句话后触发引用块片段，把它变成带引号和出处的格式。这条能力把片段从"生成器"扩展成了"变换器"，值得单独在库里开一个分组。
第三类是剪贴板历史。Raycast 和 Alfred 都维护历史记录，允许片段引用"上一条""上上条"。用法是连续复制三个值，然后一次性填进模板的三个位置。这比来回切换窗口复制粘贴顺畅得多，但也有明确风险：历史里可能残留密码、令牌、客户手机号这类敏感内容，被片段误取会造成信息外泄。建议的做法是给使用剪贴板历史的片段加一个显式前缀，并定期清空历史。
第四类是上下文感知：读取当前应用或窗口标题。Raycast 支持动态占位符取当前应用信息，Espanso 支持按应用名做过滤。用途很直接——同一个触发词，在邮件客户端里出正式版本，在即时通讯里出简短版本。这让"按场景切换内容"从人工判断变成了自动分支，也就是下一章要讲的分支能力。
失败模式必须提前设计。剪贴板为空时，不同工具的行为不一样：有的插入空串，有的插入上一次的旧内容，后者更危险，因为它看起来"正常工作"。防御写法有两条：给剪贴板变量设一个可见的默认值（比如「待确认」三个字），或者在片段里插入一个醒目的待确认标记，让空值一眼可见，而不是悄悄变成一句通顺的错话。
收益侧的数字：示意数据显示，引入剪贴板与选区占位符后，陈默小组日志里"复制—粘贴—改"这类动作占比从百分之三十四降到百分之十一。降下来的部分不是消失了，是被片段内部的占位符接管了。
组合与分支：片段调片段、按应用切换、正则替换
片段调用片段，是片段库里唯一的"单一数据源"机制。把签名块、免责声明、时效承诺这些高频公共部分抽成原子片段，让主片段引用它们。好处是改一处、处处同步；代价是引入了依赖关系，而依赖是需要治理的。陈默的做法是给被引用的原子片段加统一前缀，比如用双冒号开头，让人一眼看出"这条是给别人用的"。
按应用分支，是上下文能力的直接延伸。Espanso 支持按应用名过滤，TextExpander 支持按分组限制生效范围。同一个触发词，在邮件客户端展开成三段式正式开场，在群里展开成一句话。这里有一条经验约束：同一触发词的分支数不要超过两个。超过之后，"同一个词在不同地方表现不同"这件事本身就会成为认知负担，新人上手成本陡增，而收益递减。
正则替换式片段是威力最大、也最危险的一类。它不依赖触发词，而是在你输入时把匹配到的模式替换成目标文本。典型用法：把斜杠日期自动规整成横杠日期，把 (c) 换成版权符号。危险在于它是全局生效的输入改写器——一条写错，会污染你在所有应用里的输入，而且错误发生时你往往意识不到。
因此正则片段需要三条硬规则。第一，触发模式必须带明确边界，限定在行首、特定标点之后或特定符号组合，绝不使用可能出现在单词中间的模式。第二，新规则先在小范围启用并观察一周，确认无误伤再放开。第三，每条规则都要在片段库里写注释说明意图和反例——三个月后你不会记得当初为什么要排除某个模式。
"我给自己定的规矩是，正则片段不超过五条，"陈默说，"每加一条，都要先写清楚它会在什么情况下误伤我。写不出来，就说明我还没想明白，那就先不加。"
组合的最后一项代价是依赖深度。A 调 B，B 调 C，改 C 的时候你不知道影响了谁。建议把依赖深度限制在两层以内，并且在被引用片段的命名里标出它被谁引用。这条约定看起来繁琐，但在库超过五十条之后会救你一次。
专业分析：静态片段与半自动片段的能力对比，以及四项度量指标
先把两个公开研究的量级摆出来，作为后面推理的基线。其一，成年人的英文打字速度常见量级约为每分钟四十个英文词，中文输入约为每分钟三十到四十字，这决定了"两百字话术"这件事的量级是几分钟而不是几秒。其二，人的短时记忆容量通常被引用为七加减二个组块（Miller 1956 年的公开研究）。这两个数放在一起能说明一件事：片段的价值主线不是"更快"，而是"不占用组块"——把两百字压缩成一个触发词，本质是把五个组块压成一个，腾出来的注意力用在真正需要判断的地方。
这里补一个维护侧的命名框架，叫 LACE。L 是可读性（Legibility），判据是不展开片段也能从名字判断它插在哪；A 是原子性（Atomicity），判据是这条片段是否只做一件事、能否被别的片段引用；C 是一致性（Consistency），判据是同类片段的变量命名和停靠顺序是否统一；E 是可演进（Evolution），判据是改它的时候你能不能在两分钟内列出受影响的所有引用。四条各有一条可判定标准，季度检视时逐条打分。
静态片段与半自动片段的能力对比，可以按六个维度拉开。变量支持：静态无，半自动支持命名变量与默认值。日期能力：静态只能写死日期，半自动可计算相对日期与格式化。上下文能力：静态对当前环境无感知，半自动可读取应用、剪贴板与选区。维护方式：静态靠复制新版本，半自动靠改原子片段同步全部引用。冲突风险：静态低，半自动因正则片段与剪贴板取值而升高。上手成本：静态几乎为零，半自动需要理解语法。这张对比的核心结论是：半自动版本在覆盖力和维护方式上明显占优，代价是冲突风险和上手成本，需要用命名规范和边界验证来抵消。
真实工具的案例可以对上号。Espanso 作为开源跨平台方案，通过 date、clipboard、shell 三个扩展分别覆盖日期计算、剪贴板与上下文、以及外部命令计算；TextExpander 用 fill-in 字段和日期宏覆盖变量与日期；VS Code 用户片段用 $1、${2:默认}、TM_SELECTED_TEXT、CURRENT_DATE 这几组语法覆盖全部四层。三家的共同点是都提供了"参数、计算、上下文"这三层，差别只在语法方言，因此迁移成本主要在格式串和变量写法，不在概念。
四项可落地度量指标如下。第一，片段覆盖率，口径前文已定义，季度目标建议先定在百分之六十以上。第二，冲突率，等于"展开后三秒内撤销的次数"除以"总展开次数"，健康区间示意在百分之一以下。第三，回填率，等于"展开后零修改直接发送的次数"除以"总展开次数"，示意健康区间在百分之六十到八十之间，过低说明片段不合用，过高说明你可能把不该模板化的内容也模板化了。第四，维护成本，等于"每月维护片段库的分钟数"除以"片段总数"，用来判断库是不是已经膨胀到管不动了。
执行清单五步：第一步，导出触发日志，列出触发次数前二十和撤销次数前五；第二步，给前二十条逐一标出变量位，只标出现三次以上的变量；第三步，改造成带默认值的变量并排好停靠动线；第四步，把所有承诺时敏类内容换成日期计算，并在月末、跨年、闰年、夏令时四种边界各验证一次；第五步，治理命名与备份，加前缀、删重复、导出快照。
数据来源说明：上述百分比与计时数字，除明确标注为公开研究常见量级的部分外，均来自对单个小组三十天日志的自查清点，属于示意数据，样本量小、未经严格对照，只用于说明量级关系，不宜直接外推到别的团队。
命名规范与冲突治理：分组前缀、触发词撞车、备份与同步
分组前缀是冲突治理的第一道防线。常见的约定是用分号加短词表示短句、双冒号表示长模板、斜杠加字母表示特定类别（比如日期类）。前缀的作用不是分类好看，而是让触发词在结构上不可能与自然语言撞车——只要你用的起始符号不在正常行文里出现，展开就是可控的。
触发词撞车有两种典型形态。第一种是符号被吞：你设了分号开头的触发词，但某些输入法或某些应用会把分号处理成别的东西，导致片段永不触发或延迟触发。第二种是词本身撞车：你设了 omw 想展开成一句话，结果你在聊天里真的想打"omw"这三个字母时它就被展开了。第二种更烦人，因为它让你对自己的输入失去信任。
冲突率要能度量才有治理可言。定义是"展开后三秒内撤销的次数"除以"总展开次数"。陈默小组的示意数据：改造前冲突率约百分之八，主要来自三个用纯字母单词做触发词的片段；把所有触发词统一改成非字母前缀之后，冲突率降到百分之一以下。改动本身只花了四十分钟。
备份这件事之所以要单独讲，是因为片段库通常是纯文本（YAML 或 JSON），天然适合放进版本控制。陈默用私有仓库托管，每周提交一次，提交信息写清改了哪几条；跨设备靠同步盘加一份每周导出快照。这里的原则和任何重要文本资产一样：本地一份、同步一份、快照一份，改库之前先导出。
还有一个常被忽略的细节：导出快照要包含片段库之外的东西——触发日志、被引用关系清单、边界验证记录。因为真正难恢复的不是文本本身，而是"为什么当初这么写"的那些判断。
"我吃过一次亏，"陈默说，"换电脑的时候只导出了片段文件，没导出日志。结果新机器上我根本想不起来哪几条还在用，有十几条白留了一年。"
两周升级路线：把你的模板库搬上语法层
第一天到第二天，只做清点。导出触发日志，列出触发次数前二十和撤销次数前五。注意前二十和前五通常不是同一批——触发次数高说明确实用，撤销次数高说明用得不顺，后者才是改造的优先级。这一步不要动手改任何东西。
第三天到第五天，标变量位。给前二十条逐一标出变量，但只标出现三次以上的，不要过度参数化。判断标准很简单：如果一个位置的取值在过去三十天里只出现过一次，那就写死它；出现三次以上才值得做成变量。这一条约束能挡住大部分"为了优雅而参数化"的冲动。
第六天到第八天，改造变量与停靠点。给每个变量配默认值，默认值用上一版真实值；按人的填写顺序而不是文本顺序排停靠点；把 $0 留给需要人工复核的位置。这三天结束时，你的前二十条片段应该已经从"插入后再改"变成"填完就发"。
第九天到第十一天，处理日期与上下文。把所有承诺时敏类内容换成日期计算，并在月末、跨年、闰年、夏令时四种边界各验证一次，把验证结果写进片段注释。上下文类占位符放在这阶段的最后一天，先只给三条最高频的片段加，观察两天再铺开。
第十二天到第十四天，做治理。统一前缀、删掉重复和无人使用的条目、做一次完整导出快照、写一张一页纸的库说明贴在片段库文件的开头——内容包括命名规则、变量上限、依赖深度限制、备份位置。这张纸是给三个月后的你自己看的。
十四天结束后，重算一遍四项指标：覆盖率、冲突率、回填率、维护成本。把这组和开工前的数字并排记下来，这就是这套语法层改造在你身上的真实收益。陈默这组数字的变化是：覆盖率从百分之三十一到百分之七十九，冲突率从百分之八降到百分之一以下，每月维护时间从两百四十分钟降到九十分钟——同样是示意数据，但它说明了一件事：真正省下来的不是打字时间，是不确定性。
常见问题
1.问：片段库多大算合适，是不是越多越好？
答：不是。判断标准不是条数，而是覆盖率和冲突率这两个指标的组合。一个可执行的做法是：每季度导出触发日志，把九十天内触发次数为零的条目全部归档（不是删除，移到单独的归档文件），再重算覆盖率。如果覆盖率没有下降，说明这批条目确实可以移走。经验上的健康区间是覆盖率百分之六十以上、冲突率百分之一以下，条数本身不构成目标。
2.问：不同工具之间迁移片段，成本高在哪？
答：成本不在概念，在语法方言。变量写法、日期格式串、剪贴板占位符这三处的写法各工具都不一样，需要逐条改写；而"哪些内容该做成变量""停靠顺序怎么排"这些判断是可以原样带走的。降低迁移成本的办法是：在片段库文件里用注释把每个变量的语义单独写一行，与具体语法分开。这样换工具时你只需重写语法行，语义行可以照抄。
3.问：日期计算在各工具里语法不一样，有没有通用写法？
答：没有完全通用的写法，但可以缩小差异。做法是只在片段里使用四类最基本的计算：今天、N 天之后、上月最后一天、工作日偏移，其余复杂计算一律走 shell 扩展调用系统命令或手工确认。同时把格式串集中定义在一处，比如统一写成 YYYY-MM-DD，需要别的格式时在片段里做一次转换，而不是让每条片段各写各的。
4.问：剪贴板片段会不会泄露敏感信息？
答：有可能，而且主要风险来自剪贴板历史而不是当前剪贴板。三条可执行的防护：一是给所有使用剪贴板历史的片段加独立前缀，方便你一眼识别；二是定期清空剪贴板历史，尤其是处理过密码、令牌、客户手机号之后；三是给剪贴板变量设可见的默认值，这样取值失败时会留下明显痕迹，而不是悄悄插入上一条旧内容。
5.问：团队共用一套片段库，怎么避免互相覆盖？
答：把库拆成两层：公共层与个人层。公共层只放被三人以上共同使用的原子片段（签名、免责说明、公司口径），改动走提交评审；个人层各自维护，命名带个人前缀，互不干扰。再配一条硬规则：公共层的原子片段只允许新增和废弃，不允许直接修改内容——要改就新建一条并给新版本号，等所有人迁移完再废弃旧的。这样能避免"改了一个词，九个人的话术同时变了"这类事故。
片段的终点不是让你少打字，而是让你不必再想那些已经想清楚过的事。
图片来源：图1 Pexels / Pixabay (CC0) · 图2 GAIMARD / Pixabay (CC0) · 图3 Dedy_Timbul / Pixabay (CC0) · 图4 Pexels / Pixabay (CC0) · 图5 daschorsch / Pixabay (CC0) · 图6 MonicaVolpin / Pixabay (CC0) · 图7 romansolar / Pixabay (CC0) · 图8 DerWeg / Pixabay (CC0) · 图9 661512 / Pixabay (CC0) · 图10 dassel / Pixabay (CC0) · 图11 dassel / Pixabay (CC0) · 图12 Elsemargriet / Pixabay (CC0) · 图13 Kranich17 / Pixabay (CC0) · 图14 daschorsch / Pixabay (CC0) · 图15 Fragoso / Pixabay (CC0) · 图16 mjh_shikder / Pixabay (CC0) · 图17 fotoblend / Pixabay (CC0) · 图18 poszarobert / Pixabay (CC0) · 图19 sfkjrgk / Pixabay (CC0) · 图20 ClarissaBell / Pixabay (CC0) · 图21 webreiziger / Pixabay (CC0) · 图22 jkdvmim / Pixabay (CC0) · 图23 Pexels / Pixabay (CC0) · 图24 messomx / Pixabay (CC0) · 图25 qimono / Pixabay (CC0) · 图26 Pexels / Pixabay (CC0) · 图27 Pexels / Pixabay (CC0) · 图28 Ahmedsaborty / Pixabay (CC0) · 图29 mostafa_meraji / Pixabay (CC0) · 图30 JOEBU-ART / Pixabay (CC0) · 图31 zivica / Pixabay (CC0) · 图32 lin2015 / Pixabay (CC0) · 图33 divotomezove / Pixabay (CC0) · 图34 MaxxGirr / Pixabay (CC0) · 图35 ds_30 / Pixabay (CC0) · 图36 Derks24 / Pixabay (CC0) · 图37 schuetz-mediendesign / Pixabay (CC0) · 图38 Josch13 / Pixabay (CC0) · 图39 jonleong64 / Pixabay (CC0) · 图40 RosZie / Pixabay (CC0) · 图41 MiraCosic / Pixabay (CC0) · 图42 Dimhou / Pixabay (CC0) · 图43 MiraCosic / Pixabay (CC0) · 图44 focusonpc / Pixabay (CC0)
评论(0)