中文注释导致代码缩进错位，主因是中文字体在等宽环境下实际像素宽度大于英文，且fallback链未配置等宽中文字体；应禁用editor.fontligatures，并设置如"'fira code', 'microsoft yahei', 'noto sans cjk sc', monospace"的字体链，同时确保文件编码为utf-8无bom。
中文注释让代码缩进错位，其实是字体宽度不一致
VSCode里写中文注释后，右边的代码突然“往右偏了一格”，甚至折叠箭头和行号对不齐——这不是缩进设置错了，而是中文字体在等宽字体下实际占用像素比英文宽，而编辑器没做等宽补偿。尤其在启用editor.fontFamily自定义字体（比如"Fira Code", "Microsoft YaHei"）时，如果中文字体没被正确 fallback，就会出现「英文字母占1个字符宽度、中文占2个」的视觉错位。这种错位在Python或Shell脚本里特别明显：一行# 处理用户输入后面接if True:，冒号看起来就悬空在半路。
- 别指望靠调
editor.fontSize硬拉齐——字号变大只会放大错位 - Windows默认的
Consolas不支持中文，强行渲染会用系统默认宋体，字宽和英文不匹配 - macOS上
Menlo对中文支持较好，但若装了第三方字体插件（如Cascadia Code），可能覆盖fallback链导致错乱 - Linux Wayland环境下，
fontconfig配置缺失时，中文常 fallback 到DejaVu Sans，字宽比等宽字体宽1.3倍
强制中英文同宽：配置fontLigatures和fallback链
核心是让VSCode明确知道：「这段文本里有中文，但我要它和英文一样宽」。这靠两层控制：一是启用连字时禁用中文干扰，二是指定可靠的中文字体 fallback。
- 在
settings.json里加这两项："editor.fontLigatures": false,
"editor.fontFamily": "'Fira Code', 'Microsoft YaHei', 'Noto Sans CJK SC', monospace"
——fontLigatures: false关掉连字，避免中文被错误合字；字体链里把中文字体（如Microsoft YaHei）放在英文之后，确保中文不 fallback 到不可控字体 - 不要写
"editor.fontFamily": "monospace"——这是抽象字体名，不同系统解析结果差异极大 - Linux用户需确认
fc-list :lang=zh能列出至少一个等宽中文字体（如Noto Sans Mono CJK SC），否则fallback会失败 - macOS用户若用
JetBrains Mono，必须搭配Apple Gothic或Heiti SC作为中文 fallback，单用JetBrains Mono无法显示中文
状态栏显示“UTF-8”但注释仍错位？检查BOM和文件实际编码
状态栏显示UTF-8不代表文件真用UTF-8保存——尤其是从微信、钉钉或旧版Notepad复制来的代码，很可能带GBK编码+无BOM，VSCode误判为UTF-8后，中文字符字节被拆成两个ASCII码渲染，视觉上就“挤占了两个字符位置”，导致后续代码整体右移。
- 点击状态栏
UTF-8→ 选「通过编码重新打开」→ 试GBK或GB2312，如果错位消失，说明是编码误判 - 确认后点状态栏
UTF-8→ 选「以编码保存」→UTF-8（注意勾选「如果可能，保存为UTF-8编码」，避免生成BOM） - 批量修复用命令行：
iconv -f GBK -t UTF-8 input.py > output.py，再替换原文件 - Git提交前执行
git config --global core.autocrlf true和core.safecrlf true，防止Windows换行符干扰编码检测
终端里中文注释输出错位？那是chcp和PYTHONIOENCODING没对齐
代码里中文注释显示正常，但运行时print("处理完成")在集成终端里变成两行或压着提示符——这和编辑器无关，是终端进程（PowerShell/Git Bash）解码方式和Python输出编码打架。PowerShell默认chcp 936（GBK），但Python 3.7+默认按UTF-8输出，终端用GBK解UTF-8字节流，一个汉字变成三个乱码字符，宽度爆增。
- PowerShell用户：在
settings.json加"terminal.integrated.profiles.windows": { "PowerShell": { "args": ["-NoExit", "-Command", "chcp 65001 > $null"] } } - Python用户补一手：
"terminal.integrated.env.windows": { "PYTHONIOENCODING": "utf8" }——注意是utf8全小写，UTF-8在Windows下无效 - Git Bash用户必须设
LANG=zh_CN.UTF-8，否则即使文件是UTF-8，它也会拒绝读中文路径和输出 - 别信
Set-ExecutionPolicy RemoteSigned——这和编码完全无关，纯属权限误导
真正麻烦的是混合场景：文件用UTF-8无BOM保存、编辑器配了正确字体链、终端也切了65001，但同事用旧版Sublime保存的文件一拖进来就错位——这时候得盯住状态栏编码标识，而不是盲调字体。编码和字体，一个管“字节怎么读”，一个管“读出来怎么画”，漏掉哪层都会白忙。
