当列名有固定模式（如A_2020、B_2021）且需自动拆分前缀与后缀时，应优先用wide_to_long；它结构化提取、保留语义，而melt会丢失列名关系。
什么时候该用 wide_to_long 而不是 melt
当你的列名有固定模式（比如 A_2020、A_2021、B_2020、B_2021），且想把“前缀”和“后缀”自动拆成两列时，wide_to_long 是更干净的选择。它本质是结构化提取，而 melt 是无差别摊平——后者会丢掉列名里的语义关系。
- 用了
melt再手动str.split('_')拆列名？容易出错，尤其后缀含下划线或空格时 -
wide_to_long要求列名严格匹配stubnames + sep + suffix模式，不匹配的列会被直接忽略（无声丢弃！） -
suffix默认是r'\d+'，但如果你的后缀是'Q1'、'final'或带字母的，必须显式传正则，比如suffix=r'[a-zA-Z0-9_]+'
melt 怎么安全地处理多组前缀列（如 A_x、A_y、B_x、B_y）
如果列名是混合前缀+后缀但不规整（比如没有统一分隔符，或前缀长度不一），melt 更灵活，但得自己组织 value_vars —— 直接传全部列名列表容易漏、难维护。
- 别手写
['A_x', 'A_y', 'B_x', 'B_y']，用列表推导式动态筛选：[col for col in df.columns if col.endswith('_x') or col.endswith('_y')] - 保留原始标识列时，
id_vars必须是 list；传字符串会报TypeError: id_vars must be a list-like - 如果某列本该是
id_vars但值里有缺失，melt不报错，但后续groupby可能意外跳过整行——建议先df[id_vars].isna().sum()检查
常见错误：wide_to_long 运行后数据变少或报 KeyError
这不是 bug，而是它对输入太“较真”：列名没按规则命名，就直接过滤掉，也不警告。
- 检查所有目标列是否真的以
stubnames开头（注意大小写、空格、不可见字符） -
i参数指定的索引列必须在原df中存在，且不能有重复值（否则报ValueError: Index has duplicate keys） - 如果
j对应的新列名已存在于原表中，wide_to_long会静默覆盖——务必确认j名字唯一 - 运行前加一句：
print([c for c in df.columns if any(c.startswith(s) for s in stubnames)])，看实际匹配到哪些列
性能与可读性取舍：小数据用 melt，大数据+固定模式优先 wide_to_long
wide_to_long 内部做了向量化列名解析，比 melt 后再 str.extract 快 3–5 倍（实测 10 万行以上）；但它的代码可读性依赖命名规范——一旦列名改了格式，整个逻辑就断了。
- 团队协作项目里，如果列命名规则由上游系统决定，建议封装一个校验函数：
assert all('_' in c for c in df.filter(regex='^(A|B)_').columns) -
melt的ignore_index=True是默认行为，但若你之后要 merge 回原表，记得关掉它，否则索引对不上 - 两种方法都不支持原地修改，返回新
DataFrame；别忘了赋值，比如df_long = pd.wide_to_long(...)
'2020a' 这种异常值——动手前先花 30 秒 df.columns.tolist() 看一眼原始名字。 
