Raku嵌套列表调用fmt方法的不符合预期异常行为问询

你观察到的不一致行为属于已知的实现缺陷，并非官方有意设计，目前Raku社区已将其归类为bug。

核心逻辑说明 #

官方文档对.fmt的描述仅约定了最通用的顶层行为：遍历调用者的每一个顶层元素，对每个元素应用格式化字符串后用指定分隔符拼接。你遇到的差异核心源于List类型格式化逻辑的历史遗留分支：

• 当格式化字符串不包含宽度、补零、对齐等数字指令时，嵌套列表会先整体序列化为字符串，再应用传入的格式化规则
• 当格式化字符串包含数字指令时，List的格式化实现会自动遍历自身的元素，逐个应用格式化规则后用默认空格拼接，而非先整体字符串化

这一分支逻辑从未写入官方规范，也未纳入Roast测试集的覆盖范围，属于早期实现的疏漏。

疑问解答 #

• 你补充后的理解完全正确。两种输出的差异确实完全由格式化字符串是否包含宽度指令触发，和官方文档描述的通用行为均存在不一致。
• 该行为不属于有意设计，是典型的实现bug。相关问题已经在Raku核心仓库的问题跟踪系统中记录，仅因优先级较低暂未得到修复。
• 该行为完全不符合Raku处理列表的通用规则。Raku默认不会隐式穿透嵌套列表执行操作，除非显式调用.deepmap之类的深度遍历方法，当前fmt的不一致表现没有符合设计规范的逻辑支撑。

稳定实现方案 #

如果需要避免实现缺陷的影响，可通过显式遍历控制格式化层级：

1. 希望格式化仅作用于顶层元素（无论格式是否带宽度指令）：

(<a b c>, <1 2 3>, <X Y Z>).map(*.Str.fmt('→%03s|')).join("\n=================\n")

2. 希望格式化作用于所有嵌套的叶子元素：

(<a b c>, <1 2 3>, <X Y Z>).deepmap(*.fmt('→%03s|')).join(' ')

内容的提问来源于stack exchange，提问作者codesections