跳转到内容
Jason's Study

micro — 终端里像 VS Code 一样顺手的纯 Go 编辑器

是什么

micro 是一个跑在终端里的文本编辑器，目标是把”VS Code 那种顺手”装进一个单文件二进制。日常类比：你已经习惯电脑上的记事本，按 Ctrl+S 存、Ctrl+C 抄、鼠标点哪改哪——micro 把这套体验整个搬到了 ssh 进去的黑底白字小窗口里。

打开方式跟 nano 一样简单：

Terminal window
micro hello.txt

特别之处：你过去在图形编辑器里学的所有快捷键它几乎都直接认——Ctrl+S / Ctrl+Z / Ctrl+F / Ctrl+D 选下一处出现的词，鼠标点击放光标、拖动选区、滚轮翻页全部能用。

它的定位写在 README 第一行：nano 的精神继承者。nano 在 90 年代赢在易上手，但停在了”够用”；micro 把多光标、真彩色、Lua 插件、鼠标支持加上来，键位思路保持不变。

为什么重要

不理解 micro 的存在价值，下面这些场景会很别扭：

  • 你 ssh 进服务器要临时改一个 nginx 配置——vim 三十个键位不会，nano 没语法高亮看不清楚
  • Docker 容器里 apt install 装个编辑器，希望它单文件、零依赖、即装即用
  • 教刚学编程的同事在终端里改代码——你不想第一课就花一小时讲 hjkl
  • 你已经会 vim，但带新人 pair 的时候希望对方能直接上手不被键位吓到

micro 不是要打败 vim / neovim，而是填一个空档：终端里既要键位现代、又要单文件、还要能装插件，这三个条件放一起的选择不多。

核心要点

micro 的设计可以拆成 三个决定：

  1. 键位向 GUI 编辑器看齐：Ctrl+S 存、Ctrl+Q 退、Ctrl+C/V 复制粘贴。这意味着 vi 用户会反过来不习惯，但小白零成本上手。
  2. 单 Go 二进制，零运行时：scp 一个 10MB 文件到任何 Linux/macOS/Windows 终端就能跑，不需要 Python / Node / 系统包。
  3. Lua 写插件：插件不用编译，micro -plugin install xxx 一键装。生态比 vim 小，但写新插件的门槛低很多。

加在一起的好处：陌生服务器上 30 秒装好一个能用的编辑器——这是 vim/emacs 做不到的（要么没装要么配置一团），nano 也做不到（功能太薄）。

实践案例

案例 1：30 秒装好

Terminal window
curl https://getmic.ro | bash
./micro server.conf

下载脚本 → 拉对应平台的二进制 → 直接跑。没编译、没依赖、没 root。

适合场景：

  • 临时容器 / 一次性虚拟机：跑完就销毁，不想污染包管理
  • 公司服务器装包要走审批：一个二进制免审批
  • 给同事演示时对方机器上没有 vim（少数云镜像默认只装 vi）

案例 2：多光标改一堆变量名

打开一个文件，光标停在 userId 上，连按 Ctrl+D——每按一次就把”下一个 userId”也加进选区。改完一次性全部替换。

const userId = req.params.userId
console.log('userId:', userId)
db.find({ userId })

不用写正则、不用替换框，所见即所改。重度修改大文件场景比 vim 的 :%s 直观很多。

案例 3：写一个 Lua 插件

-- ~/.config/micro/plug/hello/hello.lua
function init()
    config.MakeCommand('hello', helloCmd, config.NoComplete)
end


function helloCmd(bp, args)
    bp:HandleCommand('echo Hello, micro!')
end

放到插件目录、重启 micro，输入 Ctrl+E 进命令行打 hello 就触发。Lua 不需要编译，改完保存重启即生效，反馈周期约 1 秒。

micro 的插件 API 暴露三类钩子：

  • command：用户主动触发（上面的 hello）
  • callback：保存 / 打开 / 光标移动等事件
  • action 覆写：把内置动作（如 Save）替换成自定义版本

写一个”保存时自动 gofmt”的插件大约 20 行 Lua，是新手认识编辑器扩展模型的最低成本入口。

踩过的坑

  1. 插件生态远不如 vim/emacs：能找到语法高亮、Git 集成、模糊搜索，但LSP 体验比 neovim 原生差不少。重度开发主力建议还是 neovim / helix。

  2. CJK + emoji 混排偶发错位：rune 宽度计算的老问题，光标位置和实际字符位置对不上。中文混英文一般没事，混 emoji 时偶发；遇到先重新加载文件能复位。

  3. 大文件加载是整体读入：>100MB 的日志会卡住或吃满内存。micro 不是为大文件设计的，需要 less 或 glogg 这种专门工具。

  4. 配置文件是 JSON：~/.config/micro/settings.json 不能写注释（标准 JSON），改起来痛苦。社区一直有提案换 YAML/TOML，没落地。

  5. 键位冲突需要排查：tmux / screen 会拦掉部分 Ctrl 组合（最经典的 Ctrl+S 在某些终端里冻屏），第一次用要先 stty -ixon 关掉流控。

适用 vs 不适用场景

适用：

  • ssh 进陌生服务器临时改配置 / 写脚本
  • Docker / Kubernetes pod 里需要一个能用的编辑器
  • 带刚学终端的同事 pair，不想先教 vim
  • 想要 GUI 键位但只能用终端的场景（远程 SSH、低带宽）

不适用：

  • 重度日常开发主力（neovim / helix 插件和 LSP 更强）
  • 百兆以上日志文件查看（用 less / glogg）
  • 纯 vi 信徒（键位思路完全不同，会反过来不习惯）
  • 需要丰富中英混排排版（rune 宽度计算偶有 bug）

历史小故事（可跳过）

  • 2016 年：Zachary Yedidia 在 reddit 发出第一版 micro，定位”nano 但更现代”，几天涨了几千 star。
  • 2017–2018：加入 Lua 插件系统、多光标、真彩色支持，社区开始活跃，star 破万。
  • 2019 年起：v1.x 走向 v2.x，配置格式和插件 API 趋稳，主流 Linux 发行版开始打包。
  • 2024 年至今：稳定维护，每年 1–2 次 minor 版本，主作者还是 Yedidia 一个人，社区 PR 评审节奏慢但持续。

micro 是一个典型的 个人作者长期维护的小工具——不像 VS Code 有大公司投入，但用户群是固定的，每年都有人在 ssh 场景下重新发现它。

学到什么

  1. 定位空档比追求大而全更重要：vim 占了”键位高效”，VS Code 占了”GUI 顺手”，micro 在中间填了”终端里 GUI 键位”这块。空档小但稳。
  2. 零依赖单二进制是 ssh 场景的杀手锏：Go 静态编译让一个文件跑遍三大平台，scp 过去就用——这条路 Python 工具走不通。
  3. 键位是用户习惯的总和：放弃 vi 的键位等于放弃一群老用户，但换来全部新手——选用户也是产品决定。
  4. Lua 插件 vs vim script：Lua 学习曲线低、性能不差，neovim 也走了这条路。脚本语言选型本身能决定生态规模。

延伸阅读

  • 官方文档：micro-editor.github.io（按”Getting started”→“Tutorial”读 30 分钟够用）
  • 仓库 README：zyedidia/micro（含截图和键位表）
  • 插件市场：micro plugins（语法高亮 / Git / 模糊搜索常用三件套）
  • neovim —— 重度开发主力的现代选择，对照看键位与插件生态差距
  • helix —— Rust 写的另一条现代终端编辑器路线，选择优先模型

关联

  • nano —— micro 的精神来源，键位向它致敬
  • neovim —— 比 micro 更强的插件 / LSP 生态，但学习曲线高
  • helix —— 同样追求”开箱即用”，但键位是 vim/kakoune 风格
  • kakoune —— 选择优先编辑模型，思路独特门槛高
  • lua —— micro 的插件语言，与 neovim 的选择殊途同归