Python partition 与 rpartition：找不到分隔符，原文究竟放在哪一格
解析一行简单的key=value时，partition能直接返回三项，看起来比split方便。但将它改成rpartition以后，没有等号的输入却从左侧字段移动到了右侧字段。如果调用代码只读取固定位置，不检查中间项，缺失分隔符可能被误解释成一个空键或空值。固定长度返回值解决了解包数量问题，却不自动替你判定输入是否符合格式。
本例在Linux与CPython 3.12.14上实跑，只使用程序内的固定测试数据，不调用网络服务。文中区分公开API含义与本次解释器的具体观察；替换实现或升级版本时，应保留样本重新验收。
AI生成的概念示意图：左段、分隔槽、右段三个托盘配合左右搜索箭头，表示搜索方向与固定三元组结构，不对应某一条输入的实际返回值；不是真实软件界面或运行截图。
完整程序与实际输出
保存为demo.py，执行python3 demo.py。程序只使用固定测试输入，代码和本次输出分别列出。
for text in ('mode=fast=debug', 'mode', '=fast', 'mode='):
print(repr(text))
print(' left:', text.partition('='))
print('right:', text.rpartition('='))
for text in ('mode=fast=debug', 'mode', 'mode='):
key, found, value = text.partition('=')
print('parse:', repr(text), 'found=', bool(found), 'key=', repr(key), 'value=', repr(value))
print('multi-character:', 'name::value::tail'.partition('::'))
try:
'abc'.partition('')
except ValueError as exc:
print('empty separator:', type(exc).__name__)本次实际标准输出：
'mode=fast=debug'
left: ('mode', '=', 'fast=debug')
right: ('mode=fast', '=', 'debug')
'mode'
left: ('mode', '', '')
right: ('', '', 'mode')
'=fast'
left: ('', '=', 'fast')
right: ('', '=', 'fast')
'mode='
left: ('mode', '=', '')
right: ('mode', '=', '')
parse: 'mode=fast=debug' found= True key= 'mode' value= 'fast=debug'
parse: 'mode' found= False key= 'mode' value= ''
parse: 'mode=' found= True key= 'mode' value= ''
multi-character: ('name', '::', 'value::tail')
empty separator: ValueError搜索方向只决定切在第一次还是最后一次
对mode=fast=debug使用partition，得到mode、等号、fast=debug；使用rpartition，得到mode=fast、等号、debug。两者都只切一次，并且把匹配到的分隔符作为独立中间项保留。它们不会把剩余等号继续拆开，因此适合某些右侧值允许包含同样分隔符的简单协议。
选择第一次还是最后一次，应该来自格式定义。若key=value规定第一个等号划分键与值，partition最直接；如果路径或标签格式明确规定最后一个标记分隔后缀，rpartition可能更合适。不能因为希望某个样本的右侧更短，就随手改变搜索方向，这可能把原本合法的键值边界整体挪走。
方法不会主动移除首尾空白，也不会解释转义或引号。文本中的每个等号都按字面参与查找。若真实配置允许引号内出现等号、跨行值或注释，单次切分不一定足够，应该使用对应配置格式的解析器。本文例子刻意只定义简单字面分隔，不假装实现完整配置语言。
没有命中时三项仍然存在
输入只有mode时，partition返回原文、空串、空串，而rpartition返回空串、空串、原文。它们都没有抛出异常，也没有缩短返回值数量。原文放置方向与搜索方向相呼应，保持了各自的拆分约定。若只是解包为left、sep、right，语法完全成功，却还没有证明sep真的存在。
最可靠的命中标志是中间项found。由于分隔符不能为空，只要找到了它，中间项就是非空分隔符；找不到时中间项为空。因此示例用bool(found)报告是否命中，而不是检查左段或右段是否为空。左段为空可能只是等号位于开头，右段为空也可能只是等号位于末尾。
这使mode和mode=保持可区分：两者的value都为空，但前者没有分隔符，后者有一个明确等号。业务可以规定前者是格式错误、后者是合法空值；也可以选择其他规则。关键是不要在解析第一步就把二者合并，导致后续验证失去判断依据。
空键、空值和多字符分隔分别验收
=fast得到空键、等号、fast，mode=得到mode、等号、空值。对这两种输入，partition与rpartition的结果一样，因为只有一次命中。是否允许空键与空值应分别校验，不能用“只要有等号就是有效配置”概括。程序展示结构事实，不在示例里偷偷把空字符串换成默认内容。
分隔符可以是完整的多字符字符串。本例name::value::tail按第一个双冒号切成name、双冒号、value::tail，两个冒号被视为整体子串，而不是“任意一个冒号”。如果希望支持多个不同分隔符，需要另行定义优先级与匹配规则，partition的sep参数不会自动解释成字符集合。
空分隔符会抛出ValueError。程序捕获并打印异常类型，强调“找不到非空分隔符”和“传入非法的空分隔符”不是同一种情况。前者是正常返回三元组，后者是调用参数错误。若分隔符来自用户配置，应在入口校验，不能只依赖后面found的真假来处理所有错误。
保留原始语义，再做清理与校验
示例先partition，再查看found、key和value。如果协议允许键两边空白，可以在确认结构后只清理键；若值里的前导空格有意义，就应保留。无差别地先strip整行，可能把用户明确写入的值改掉。文本清理的顺序也属于格式设计，最好用有空格的反例明确记录。
当重复键存在时，partition只负责解析一行，并不决定后来的值覆盖前面的值，还是应该报错。相同地，它也不负责类型转换、布尔解析或数字范围检查。将每个阶段的责任拆开，有助于在报错时区分“缺少等号”“键为空”“键重复”和“值不合法”，避免所有问题都被包装成模糊的配置错误。
固定三元组还有一个实用优点：可以在审计记录中保留命中标记和原文，重建当时的解析决定。对合法命中，左段加分隔符加右段能还原原文本；对未命中，也能根据中间项判断并取回完整原文。但这并不意味着应该记录密码或令牌等敏感配置，调试信息仍要按数据敏感度控制。
回归测试至少覆盖无分隔、单个分隔、多个分隔、开头、结尾、连续分隔和空输入。分别验证返回结构与业务接受结果，避免把字符串方法测试和配置规则测试混在一起。未来从partition切换到rpartition时，这些样本会立即指出缺失分隔符的字段归属变化，防止一次看似简单的重构改变默认行为。
还有一种常见误用是用if value判断是否存在赋值。它会把mode=的显式空值和mode的缺失分隔都归入同一分支，甚至可能再补上默认值。应先检查found决定语法是否完整，再按业务检查value是否允许为空；默认值何时使用也应单独规定。三元组真正提供的价值，是保留下这一点额外结构信息，而不只是让解包代码更短。
参考资料与验证记录
官方资料核验于2026年10月3日。本次完整程序退出码为0，标准错误为空；例子验证的是上述固定输入与运行环境，不表示所有平台和版本的输出细节完全一致。
