atom-aligner 默认不支持冒号对齐，需安装 language-specific 插件（如 aligner-python）；对齐须选中干净的 key-value 行、统一缩进与软制表符，并确保文件语法被正确识别。
atom-aligner 默认不支持冒号对齐，必须装 language-specific 插件
只装 atom-aligner 本身，对 : 是无效的——它连冒号分隔符都不会识别。真正起作用的是按语言拆分的子插件，比如 aligner-python（用于 Python 字典）、aligner-json（用于 JSON 对象）或 aligner-yaml。这些插件才内置了对 : 的解析逻辑和对齐策略。
常见错误现象：
- 选中三行
"name": "Alice"类似内容，按快捷键没反应 - 右键菜单里没有
Align选项，或点了没变化 - 对齐后只有等号生效，冒号全被忽略
实操建议：
- 确认已安装对应语言插件：Python 项目必装
aligner-python，JSON 文件用aligner-json - 检查文件语法是否正确识别：右下角状态栏应显示
Python或JSON，不是Plain Text；若显示错误，手动点击切换 - 插件安装后无需重启 Atom，但需确保文件已保存（部分插件依赖文件后缀触发）
选中范围决定对齐结果，冒号对齐必须“干净选中”
atom-aligner 不走 AST，纯靠字符串扫描找最左共有的 : 位置。所以你选中什么，它就扫什么——混入花括号、缩进空格、注释甚至空行，都会干扰匹配。
典型失败场景：
- 选中整个字典块（含
{和}），对齐失败 - 某行末尾有注释如
"age": 30, # years，冒号后多出空格+符号，导致该行被跳过 - 缩进不一致（部分行用 2 空格，部分用 4 空格），对齐列错位
实操建议：
- 只选 key-value 行本身，例如：
"name": "Alice" "city": "Beijing" "role": "engineer"
不要包含{、}、空行或注释行 - 用
Shift + ↓逐行选中，避免鼠标拖动误选空白字符 - 对齐前先统一缩进：选中全部 key-value 行 → 右键 →
Editor: Auto Indent，或按Ctrl+Alt+I
对齐后缩进错乱？关键看 tabWidth 和 soft tabs 设置
对齐填充用的是空格，不是制表符。如果 Atom 的 Tab Length 设为 4，但项目规范是 2 空格，那对齐产生的空格数就会多一倍，造成视觉偏移，ESLint 也可能报 no-mixed-spaces-and-tabs。
容易被忽略的细节：
- 右下角显示
Tab: hard时，对齐必然失败——因为atom-aligner只处理空格填充 - 即使勾选了
Soft Tabs，若当前文件已存在硬制表符，插件不会自动转换 -
Tab Length在 Settings → Editor 里设，但某些插件（如atom-beautify）会覆盖该值，需单独检查
实操建议：
- 打开 Settings → Editor，确认
Tab Length= 2（或项目实际值），且Soft Tabs已勾选 - 点击右下角
Tab: hard，切换成Tab: soft；若不可点，先执行Editor: Convert Tabs to Spaces - 对齐后若仍有错位，用
Ctrl+F搜\t，手动替换为空格（启用正则模式）
Python 字典想打印对齐？f-string 才是终端里的真绝招
编辑器对齐解决的是源码可读性，但运行时输出仍是左对齐。如果你要的是控制台里美观展示字典，atom-aligner 完全不参与——得靠 Python 自身格式化。
核心逻辑很简单：算出最长 key 长度，再用 f"{k}: {v}" 动态对齐。不用第三方库，原生 f-string 就够用。
示例代码：
data = {"name": "Alice", "city": "New York", "occupation": "Developer"}
max_key_len = max(len(k) for k in data.keys())
for k, v in data.items():
print(f"{k:<{max_key_len}}: {v}")输出效果：
name : Alice city : New York occupation : Developer
注意点：
表示左对齐并占满指定宽度，别漏掉冒号- 如果 key 含中文，需考虑 Unicode 占位（Python 3.12+ 已修复，旧版本建议用
unicodedata.east_asian_width补偿） - 嵌套字典或复杂 value（如 list）需先
json.dumps(v, ensure_ascii=False)再格式化，否则易换行错乱
真正麻烦的从来不是怎么对齐，而是对齐之后要不要维护——编辑器里手动对齐的代码，下次增删 key 时大概率又变歪；而 f-string 方案只要数据结构不变，输出永远稳。
