上周有个朋友甩过来一句话：把清单里的几条划掉，要划得像手写那样、一道线从字中间穿过去。他前后试了三四个备忘录，结果一个压根找不到删除线入口，一个划完复制到聊天框里那道线就没了，还有一个看起来划得好好的，导出成纯文本之后划线凭空消失，只剩下一堆挤在一起的怪符号。这事我遇到过太多次了——“删除线”这三个字背后其实是两条完全不同的技术路线，一条走的是文字样式，另一条是把划线当成字符硬塞进文本里。搞混这两条路，就会出现“在我这儿划得好好的，发出去就散了”的尴尬。备忘录、便签、笔记、待办清单里怎么把字真正划掉，哪种方式跨设备还能保住，批量处理的时候怎么写脚本，踩过的坑又集中在哪几个位置——这篇就把我这些年折腾划线文字的完整经验摊开讲，从完全不懂技术只想点个按钮的，到想自己写脚本批量生成带删除线文本的，都能找到能直接抄的部分。
1. 先分清“样式删除线”和“字符删除线”，这是所有问题的分水岭
很多人以为删除线只有一种，实际上从实现层面看，它至少分成两个完全不同的家族。你在这两个家族之间来回切换而不自知，就会出现各种“明明划了却没划上”的诡异现象。先把这两个概念分清楚，后面所有的操作和排错才有落脚点。
1.1 富文本删除线：文字还是那些文字，只是被“涂”了一道
富文本删除线本质上是给一段文字附加了一个属性标记，告诉渲染引擎“请在这段文字中间画一条横线”。文字本身的编码没有发生任何变化，“苹果”还是两个字符，只是多了一个“strike”或者“line-through”的装饰属性。这就像你在纸上用荧光笔涂了一道，纸上的字没变，变的是纸的表面。
这种方式的优点是干净——文字内容、字数统计、搜索匹配、复制粘贴的内容全都正常，只在显示层多一道线。缺点是它依赖容器：备忘录里支持，复制到聊天软件里就没了；文档里支持，贴进纯文本框就消失了。你划掉的是“显示效果”，不是“文字本身”。
在实际应用中，富文本删除线的典型载体是各类笔记软件的编辑器和网页的样式系统。写前端的人对这个再熟悉不过，一段text-decoration: line-through就能搞定。而在移动端的便签里，它通常被包装成选中文字后弹出的一个图标——一条横线穿过一个字母的那种。
1.2 字符删除线：把斜杠真的塞进了字符里面
另一条路完全不同。Unicode 里有一批特殊的“组合字符”，它们不单独占一个位置，而是叠加在前一个字符身上，像一个贴纸贴上去。最常用的删除线组合字符是 U+0336（长横线覆盖），你把“苹果”写成“苹̶果̶”，看起来就是被划掉的样子。
关键在于：这里的“苹”和“̶”是两个独立的字符。整段文字的长度直接翻倍，你在搜索框里输入“苹果”是搜不到“苹̶果̶”的，因为中间夹了看不见的东西。它不依赖任何软件支持删除线样式，只要能显示文字的地方就能显示——聊天框、短信、二维码、纯文本框，全都能保住那道线。
代价也很明显：字体支持不好的地方会显示成方框、错位、或者干脆把组合符单独渲染在后面；字数统计会翻倍；排序和检索会彻底乱套。这条路解决的从来不是“排版”，而是“让这道线跟着文字走”。
1.3 两条路的对照表：什么场景该走哪条
| 对比维度 | 富文本删除线 | 字符删除线（组合符） |
|---|---|---|
| 文字编码是否改变 | 不变 | 每个字后面多一个组合符 |
| 跨平台保真度 | 差，离开编辑器就丢 | 好，只要字体支持就能显示 |
| 字数统计 | 正常 | 翻倍 |
| 搜索能否命中 | 能 | 一般不能 |
| 复制到纯文本框 | 线消失 | 线保留，但可能显示错位 |
| 适合的场景 | 正式笔记、文档修订 | 聊天、短文本、一次性标记 |
| 主要风险 | 换环境失效 | 破坏文本结构、影响检索 |
我个人的判断标准很简单：这段文字如果还要被检索、被统计、被机器处理，就走富文本；如果只是一次性给别人看的短句，走字符删除线更省事。搞反了，麻烦就来了。
2. 备忘录和便签里到底怎么把字划掉：分端口的真实路径
不同的设备、不同的应用，删除线的入口藏得深浅完全不一样。我有一次在一个桌面便签里找了十分钟才发现在右键菜单的二级子项里，而手机端可能只是长按选中后菜单第一屏的第三个图标。下面按端口把常见路径梳理一遍，找不到的时候对着查。
2.1 桌面端：优先试快捷键，其次翻格式菜单
桌面端笔记软件的删除线快捷键没有统一标准，但常见的有这么几个：Ctrl + D（注意，很多软件里这个键是“复制”，别乱按）、Ctrl + Shift + X、Alt + Shift + 5、Ctrl + 5。如果你用的编辑器是那种“输入符号自动转换”的类型，敲两个波浪号再输入内容、结尾再敲两个波浪号，回车就会被转成删除线，这个在支持轻量标记语法的编辑器里非常普遍。
找不到快捷键的时候，去“格式”菜单里找。它通常和加粗、斜体、下划线放在一组，图标是一条横线压在字母上。部分软件会把它折叠在“更多格式”里，需要先把工具栏展开。桌面端的好处是选中文字后右键菜单里基本都有，这是一个普适的兜底方案。
这里有个容易忽略的细节：桌面端的删除线往往跟“编辑模式”绑定。如果你是只读状态、预览状态，工具栏是灰的，这时候怎么点都没反应，不是软件坏了。
2.2 移动端：选中文字后弹出的浮动菜单是主战场
手机上的路径更统一一些：长按文字进入选择状态，拖动两端的手柄圈住要划的范围，然后看弹出的浮动菜单。删除线的图标一般是一个带横线的字母，如果没有在第一屏，点一下展开箭头或者“更多”，通常能找到。部分输入法还会在选中文字后自动扩展出一个快捷菜单，那里也可能藏着格式化按钮。
要注意的是移动端存在“两级编辑器”的问题。有些便签应用在列表页预览时是纯文本，点进去才是富文本编辑器，你在列表页怎么长按都出不来格式菜单。一定要确认自己进的是编辑态。
另外一个坑：某些安卓便签的长按菜单里，“删除线”和“删除”两个词挨得很近，误触概率不低。我吃过一次亏，两条购物清单被整行删掉，还没法撤销。操作慢一点，看清楚再点。
2.3 在线协作文档：入口更明显，但权限会拦你
在线文档一般把格式栏常驻在顶部，删除线图标一眼能看到。真正的问题不在找按钮，而在权限——如果你的账号对该文档只有评论权限，格式工具栏可能整个是灰的，你会以为是没有这个功能。
还有一种情况是多人在线编辑时的“样式冲突”：A 加了删除线，B 在同一段上取消，最后取决于谁的操作落在后面。这类文档的修订模式通常会把删除线当作“建议删除”的标记，和普通的格式删除线在视觉上是一样的，但语义完全不同。如果你在协作文档里看到一堆划线文字，先确认一下当前是不是在修订模式，否则容易误解别人的意思。
2.4 输入法自带的花样字：最省事的字符删除线入口
如果你的目的是“发出去的文本自带划线”，而不是“在笔记里标记”，很多输入法的符号面板里就有现成的修饰字符。路径一般是打开符号大全、找到“特殊符号”或“组合符号”分类，里面有一栏是各种覆盖符。选中后插在文字后面即可，但它一次只能作用在前一个字符上，所以你得一个字一个字地插。
这正是大多数人放弃这条路的原因——手动插十个字要插十次，效率太低。所以真要批量做，还是得靠脚本，下一节会讲。不过在只划两三个字的时候，输入法这条路确实是最快的。
3. 用脚本批量生成“字中间划线”的文本
手动插组合符的效率低到不可接受。一段二十个字的句子要点二十次，还得保证每次都插在正确的位置。写脚本是唯一可行的方式，而且这段代码短到可以记在脑子里，随时用。
3.1 U+0336 到底做了什么：一次字符层面的拆解
先说清楚原理。Unicode 里有一类字符叫“组合附加符号”，它们的特性是：渲染时不会前进光标，而是回退并叠加到前一个字符上。U+0336 的名字是“COMBINING LONG STROKE OVERLAY”，翻译过来就是“长横线覆盖”，它的作用就是在前面那个字符的正中间横着画一道线。
除了它，还有几个相关的：
- U+0335（短横线覆盖）：线条比字符窄，适合窄字符，但在汉字上会显得很短
- U+0337（短斜线覆盖）：一条短斜杠
- U+0338（长斜线覆盖）：一条贯穿的长斜杠，做“打叉”效果常用
- U+20E5（反向斜线覆盖）：反方向的斜杠
- U+0332（下划线覆盖）：画在下方，用来做下划线
- U+0330（下方波浪线覆盖）：就是那种红色的波浪提示线效果
在中文语境里，用得最多的是 U+0336，因为汉字是方块字，横线长一点才明显。但要注意，横线能不能对齐到字符垂直居中的位置，完全取决于字体有没有为这个组合符做定位适配。字体没做适配的话，你会看到线画得太高、太低，或者干脆变成一个孤零零的小横杠跟在字后面。
3.2 一段能直接跑的生成代码
Python 版本，处理中文和英文都可以：
STRIKE = "\u0336" def strike(text: str) -> str: # 每个字符后面追加一个组合删除符 return "".join(ch + STRIKE for ch in text) def unstrike(text: str) -> str: # 反向操作，把组合删除符剥掉 return "".join(ch for ch in text if ch != STRIKE) if __name__ == "__main__": demo = "这份清单里的三项已经完成" marked = strike(demo) print(marked) print(len(demo), len(marked)) # 长度会翻倍 print(unstrike(marked))JavaScript 版本，适合放在网页工具里：
const STRIKE = "\u0336"; const strike = (s) => Array.from(s).map((c) => c + STRIKE).join(""); const unstrike = (s) => Array.from(s).filter((c) => c !== STRIKE).join(""); console.log(strike("暂缓执行"));这段代码有两个地方值得多说一句。
第一，Python 里为什么要用"".join(ch + STRIKE for ch in text)而不是简单的text.replace？因为replace只能替换已有字符，而这里是要在每个字符后面“插入”一个新字符，位置逐字变化，只能走逐字符拼接。用生成器表达式拼字符串比用+=快得多，字符串长了差距会很明显。
第二，JavaScript 里为什么要用Array.from(s)而不是s.split("")？因为split("")是按 UTF-16 码元切分，遇到 emoji 或者超出基本平面的字符会被切成两半，导致组合符插在半个字符中间，输出就乱了。Array.from按码点切，安全得多。这个细节我在处理带表情的文案时踩过，输出一塌糊涂，排查了半天才发现是切分方式的问题。
3.3 长度翻倍带来的连锁反应：不只是字数统计变难看
生成之后，最直观的变化是长度。每个字符后面跟一个组合符，字符串长度精确地乘以 2。这个变化会在很多地方引发连锁反应，而且大部分是隐性的。
字数统计首当其冲。你写了一句话，编辑器的字数显示翻倍，有些应用还会因为超长而截断。更麻烦的是数据库层：如果某个字段的长度限制是按字符数算的，你以为只写了 50 个字，实际存储了 100 个码位，可能刚好卡在限制线上被拒绝。
检索是第二个重灾区。搜“完成”找不到“完̶成̶”，因为中间夹了组合符。如果这批文字是要被别人搜到的，用字符删除线基本等于放弃了可检索性。有些系统做了归一化处理（比如比较前先剥离组合符），但这种情况属于少数，不能指望。
排序是第三个。字符串比较是按码位逐位比的，组合符会参与比较，导致排序结果莫名其妙地乱。如果你把带删除线的文字放进一个需要排序的列表，出现乱序是正常的，不是 bug。
还有一个隐蔽的问题：正则匹配。\w+、\S+这类模式会把组合符当成独立字符匹配进去，你写的一堆清洗规则可能全部失效。做数据清洗的时候，第一步就该把组合删除符过滤掉。
3.4 反向清理：拿到一堆带划线的文字怎么还原
经常有人从别处复制来一堆带删除线的文字，想还原成干净的。上面那段unstrike是最基本的版本，但实际场景里往往不止一种组合符。
稳妥的写法是把常见的组合覆盖符列成一个集合，逐个剔除：
import unicodedata OVERLAYS = { "\u0336", "\u0335", "\u0337", "\u0338", "\u20e5", "\u0332", "\u0330", "\u0334", } def clean(text: str) -> str: return "".join(ch for ch in text if ch not in OVERLAYS)如果范围不确定，可以用unicodedata.combining(ch)判断，返回值非 0 表示这是一个组合字符，全部剔除：
import unicodedata def strip_all_combining(text: str) -> str: return "".join(ch for ch in text if not unicodedata.combining(ch))注意这里有个副作用：它会把正经的拼音声调、阿拉伯语元音符号、部分语言的重音符号一并剥掉。如果你处理的文本里混有其他语言的正常组合符，就得回到白名单方式，只剔除你确认的那几种。
4. 划不上、划歪了、一粘贴就没了：常见故障的排查链路
我遇到过的删除线相关问题，八成集中在下面四个位置。它们看起来症状相似，根因完全不同，得分开处理。
4.1 显示成方框、断开或者错位：字体没适配组合符
这是字符删除线最常见的翻车方式。症状是：线条不在字中间，而是飘在字上方、压在底部，或者干脆在字后面显示成一个单独的小横杠，中间还空了一格。
根因是字体缺字形定位数据。组合符叠加在哪个位置、画多长、粗多少，需要字体文件里为每一对“基字符 + 组合符”提供定位信息。中文字体在这块普遍不如拉丁字体完善，尤其是笔画复杂的字，横线容易画到不该画的位置。
应对办法有两个方向。一是换字体，试试系统默认字体、思源系类字体，效果会好一些。二是改策略，放弃字符删除线，改用富文本样式，或者干脆用文字说明代替划线。
还有一个容易忽略的因素：行高。组合符本身不占行高，但如果字体渲染时把它算进了行框，整行的行距会变得不均匀。排版要求高的时候，这个必须考虑。
4.2 粘贴到聊天框之后线消失了：那是富文本删除线
如果你在备忘录里划得好好的，复制到聊天窗口之后线没了、字还在，几乎可以断定：你用的是富文本删除线（第 1.1 节那种）。复制动作走的是纯文本剪贴板通道，只搬字符，不搬样式，那道线自然留不下来。
判断方法很简单：在备忘录里把光标放在被划掉的字中间，按一下左右方向键。如果光标一格一格正常移动，字符数没变，那就是样式删除线；如果按一次方向键光标“卡”在原地或者要按两下才动，说明中间夹着组合符。
想保住线，只有两条选择：要么在目标环境里手动重新加一次样式（如果它支持），要么换成字符删除线重新生成。没有第三条路。
4.3 搜不到、排序乱、字数翻倍：字符删除线的结构性代价
这三个症状是绑在一起出现的，根因都是同一个：组合符占用了真实的码位。
排查顺序建议这样走。先看字数：写十个字显示二十个字，基本可以确认走了字符路线。再看搜索：复制一个“看起来正常”的词去搜，搜不到就说明中间有东西。最后看长度限制：如果提交时被截断或者报错，就是长度超限。
处理方式取决于这个文本后续怎么用。要长期存档、要被检索、要参与计算，那就整批清理掉组合符，改回普通文本；只是临时展示，那就接受它的代价。
提示：做数据导入的时候，建议在入口处统一过滤组合覆盖符，一次性把问题堵在源头。这比后期逐条排查省事得多。
4.4 表格单元格和代码块里的异样表现
表格里的删除线有个独有的问题：单元格的宽度是根据内容自动计算的，加上组合符之后内容的“视觉宽度”没变，但“码位宽度”翻倍了，某些渲染引擎会把单元格撑得很难看，或者反过来截断内容。
代码块里更要注意。很多编辑器会把代码块设为等宽字体，等宽字体对组合符的定位支持通常更差，经常出现线条完全错位的情况。而且在代码块里插入组合符，本身就会破坏代码的语法——虽然看起来只是多了划线，但对解析器来说那是一堆非法字符。
我的建议是：代码块里绝对不要用删除线，无论哪种。要标注某行代码作废，用注释符号，别用划线。
5. 删除线到底该用在哪：几个真实够用的场景
功能搞明白之后，剩下的问题是什么时候用。我用一个原则来判断：删除线的语义是“这条内容曾经存在、现在作废，但过程信息有价值保留”。不符合这个语义的，就不该用。
5.1 待办和购物清单：勾销的仪式感比正确性更重要
这是删除线使用频率最高的地方。买菜清单里买到一样划掉一样，划掉的动作本身就是反馈——它告诉你“这件事处理完了”，比打勾的反馈更强烈。因为划掉是“破坏性”的，视觉上那条内容被“废掉”了，心理学上更接近真实的“扔掉”。
这种场景我建议一律用富文本删除线，不要用字符版本。原因很实际：清单里的内容经常要复制到聊天里发给别人（“这几样帮我带一下”），如果带了一堆组合符，对方收到的东西会很奇怪。而且清单不需要检索，富文本已经够用。
有一点要注意：清单类应用如果支持“已完成的自动划线”，那就更别手动了。让系统管状态，你只管内容，属性由程序控制，不会因为误操作把已完成变成未完成。
5.2 学习笔记里标记“改口”和“错误理解”
看教材或者听讲解的时候，经常出现“我原来的理解是 A，后来发现应该是 B”的情况。这时候把 A 划掉，后面写上 B，保留完整的认知修正轨迹，比直接删掉 A 有价值得多。删掉之后你只记得对的，不记得为什么错，下次还会错在同一个地方。
这种用法对格式的稳定性要求很高，因为笔记是要长期翻看的。建议走富文本，同时在旁边加个简短的批注说明为什么改。只划不写原因，过三个月你自己都看不懂当时在想什么。
5.3 文稿修改和版本留痕：划线只是辅助，别当正式手段
改稿子的时候把删掉的部分划掉、保留原文，是编辑工作里的常见做法。这里我要提醒一句：如果这份文稿要正式交付或者被多人审阅，不要靠删除线来做修订标记，用软件自带的修订记录功能。删除线只是视觉标记，它没有时间戳、没有操作人、没有接受/拒绝的动作，别人无法判断这条内容是你删除的还是本来就标记为有问题的。
5.4 明确不该用的地方：代码、数据、对外正式文本
有三类内容我是坚决不用删除线的。
第一类是代码。原因上面说过，组合符会破坏语法，富文本删除线在复制到 IDE 时也会丢失，两边都不讨好。
第二类是结构化数据。表格里的数字、编号、状态字段，一旦带上删除线，导出和导入就会出问题，尤其跨系统传输的时候，本来干净的字段变成一堆带组合符的字符串，下游处理全乱。
第三类是对外发布的正式文本。给客户的文档、公开的说明材料里出现划掉的字，容易被理解成“这部分我们不确定”或者“这里出过错”。删除线在非正式场景是效率工具，在正式场合是沟通成本。
6. 用了这么多年，我总结出的几条实操原则
有一条我踩过坑才认的：先确认目标环境，再决定用哪种划线。写之前花三秒想一下，这段文字最后会落在哪——留在编辑器里、发到聊天框、还是要被存进数据库。定了落点，划线方式基本就定了，比事后返工省事太多。反过来做的人，我见过太多，都是先划了再到处找为什么线没了。
第二条是关于批量处理的：超过五个字就别手动插组合符。手动插的错误率高得离谱，稍微一快就插到错误位置，或者前后字符选错，输出看起来像是中间少了一个字。宁可花两分钟写个一次性脚本，也别手点二十次。
第三条关于备份：字符删除线属于“有损修改”。一旦你把文字转成带组合符的形式，原来的干净文本就不存在了，除非你另存一份。我现在的习惯是生成之前先复制一份原文到剪贴板或者临时文件，生成完对比一眼再决定要不要覆盖。这个习惯救过我两次，有一次脚本里字符集写错，把整段文字都搞乱了，幸好原件还在。
第四条是给别人发带划线的文字时，顺手附一句纯文本版本。你那边字体渲染得好好的，对方那边可能是三个方框。特别是跨设备、跨系统发的时候，这个概率不低。多打一遍字的成本，远低于对方看不懂来问你三遍的沟通成本。
最后一条，也是我觉得最值得说的：划掉不等于删除，别把两者混为一谈。删除线保留的是“这个内容存在过”的信息，这个信息本身有价值；真正不想留痕的东西，就应该直接删掉，别用划线假装保留了过程又让人看不清结论。我见过一些文档，一半内容是划掉的，读起来要不停在“有效”和“作废”之间切换，阅读效率极低。划线是为了让读者更清楚，不是为了让自己更省事——这条判断标准，比任何技术细节都管用。
