nicknisi/dotfiles：一份把整台 Mac 交给 Mise 的配置仓库

一份不是给大众用的 dotfiles

仓库 README 第一句就划清了界限：这是作者实际在用的配置，不是 starter kit。它假设你有一台 Apple Silicon 的 Mac，仓库克隆在 ~/Developer/dotfiles，并且 ~/Developer 下还有作者其他几个仓库。这种假设把可移植性直接牺牲掉了，换来的是作者自己机器上的一次性完整复现。对读者来说，这份仓库的价值不在「拿来即用」，而在观察一个人如何用 Mise 把 Homebrew、符号链接、Git 配置、macOS 默认设置和运行时安装全部收进一个 config.toml。它更像一份技术方案文档，而不是分发工具。

Mise bootstrap 是真正的核心

整个安装过程围绕 config/mise/config.toml 展开，这份文件被称作 machine manifest。mise bootstrap 的执行顺序是：先跑 macOS 的 pre-packages 钩子装 Homebrew 和字体，再按 [bootstrap.packages] 装系统包，接着从 [bootstrap.repos] 克隆作者的仓库，然后应用 [dotfiles] 里的符号链接，设置 macOS defaults 和登录 shell，最后安装 [tools] 里的运行时。这个顺序是精心排过的，Homebrew 必须先于需要它的包，符号链接要在 shell 配置生效之前就位。install.sh 的职责很轻，它只检查 Git、克隆仓库、装 Mise，然后调用一次完整的 bootstrap。也就是说，首次安装和日常更新走的是同一条路径，不是两套逻辑。

符号链接用目录级声明，不用逐文件

Mise 的 dotfiles 链接不是逐个文件列出来的，而是两条宽泛的目录映射：~/.config/* 对应 config/*，~/.??* 对应 home/.??*。这种做法的好处是新增配置文件时不用改 manifest，坏处是源路径被写死。仓库必须放在 ~/Developer/dotfiles，否则链接全断。README 明确提示了这一点，除非你手动改 manifest。管理命令也值得注意：mise bootstrap dotfiles status 查看状态，apply 和 unapply 可以针对单个目标，比如只链接 ~/.config/nvim。Mise 拒绝用符号链接覆盖真实文件，除非加 --force。这意味着你在删除或重命名源文件之前，必须先 unapply 对应目标，否则会留下悬空链接。README 给了两条 find 命令来找出这些悬空链接，但它们只打印候选，删除前要逐个确认。

安装流程的硬性前提

curl 安装命令看起来简单，但 README 在下面列了三个硬前提。第一，Apple Silicon 的 Homebrew 路径必须在 /opt/homebrew，Intel Mac 或自定义路径都不行。第二，bootstrap 需要可用的 GitHub SSH key，因为 [bootstrap.repos] 里声明的三个仓库都是走 SSH 克隆的，不是 HTTPS。第三，在 Mac 上第一次运行如果缺 Xcode Command Line Tools，安装器会打开 Apple 的安装界面然后停止，你得手动装完再跑一次。还有一点，作者自己的几个工具，比如 diffdad、fleet、tm、sessions，在 Linux ARM 上会被跳过，因为它们的 release 没有 ARM 资产。这意味着 devcontainer 里跑出来的环境并不完整，它只是用来验证终端配置的。

机器本地 Git 身份与全局配置分离

安装完成后，作者要求运行 mise run setup-git 来写 ~/.gitconfig-local。这个文件由 setup-git 任务询问姓名、邮箱和 GitHub 用户名后生成，它被跟踪的 Git 配置 include 进来，但本身永远不会提交。这个设计把公开的 dotfiles 和私人的身份信息分开了，比把邮箱写死在仓库里干净。类似的模式也出现在 shell 配置里：~/.zshenv.local、~/.localrc、~/.zshrc.local 这三个文件如果存在就会被加载。也就是说，这台机器的个性化内容都放在本地覆盖文件里，仓库本身只保留可分享的默认值。对想借鉴的人来说，这个「跟踪配置 + 本地覆盖」的分层思路比 Mise 的具体用法更有移植价值。

更新路径集中成一条命令

mise run update 是唯一的更新入口，它同时处理 Neovim 插件、Homebrew、zsh 插件、Mise 工具、uv 工具、Pi 扩展和仓库本身。这种集中式更新有利有弊。好处是日常维护只有一个命令，不用分别记 lazy.nvim 的更新键、brew upgrade 和 mise upgrade。坏处是某一步失败会阻断整条链路，而且把这么多工具的更新绑在一起，出问题时定位范围会变大。另外，这个 update 任务只更新工具和插件，不重新应用符号链接，也不重跑 macOS defaults。如果你改了 manifest 里的链接声明，还是得手动跑 mise bootstrap dotfiles apply。

devcontainer 的定位是烟雾测试

仓库里有一个 .devcontainer，它用 Ubuntu 跑同一套 bootstrap，目的是让作者在 Linux 容器里编辑和检查可移植的终端配置，而不影响宿主机。但正如前面说的，Linux ARM 上会跳过几个作者自己的工具，所以这个容器环境不是完整镜像。它更像一个 CI 烟雾测试，验证 zsh、Neovim、tmux 这些纯终端配置在 Ubuntu 上能正常加载。对读者来说，如果你想把这份配置改成自己的，devcontainer 是一个低成本的试验场，不用碰宿主机就能试 shell 和 Neovim 的配置。但要注意，macOS 专属的部分，比如 AeroSpace、SketchyBar、Karabiner-Elements，在容器里根本不会安装。

维护成本与许可证

这份仓库的维护成本集中在 Mise 的版本管理和工具链更新上。README 显示运行时固定了 Node.js 24 和 Python 3.14.7，这些版本号会过期，需要作者定期更新 manifest。工具列表很长，从 1Password CLI 到 superfile 都有，任何一个工具的升级都可能破坏配置。许可证是 MIT，这意味着你可以自由复制和修改，但仓库里大量配置是作者的个人偏好，比如 Monaspace 字体、Tokyo Night 主题、Pi 和 Claude Code 这两个 CLI agent，这些选择没有普适性。想 fork 的人要清楚，你继承的不只是代码，还有作者对工具的口味。真正值得复用的是 Mise bootstrap 的 manifest 结构，而不是这份清单本身。

编辑结论

适合想理解 Mise bootstrap 如何承担整套机器配置的人阅读，尤其是已经用 Mise 管理工具版本、想从分散的 shell 脚本迁移到声明式 manifest 的开发者。不适合想要一份开箱即用、跨平台通用配置的人，这份仓库硬编码了 Apple Silicon、/opt/homebrew、~/Developer/dotfiles 和作者的 SSH 仓库，直接 clone 到其他机器上大概率跑不通。动手之前先确认三件事：你的机器是不是 Apple Silicon，GitHub 上有没有可用的 SSH key，以及你是否愿意接受把个人 bin 脚本和第三方仓库配置一并纳入管理。这份配置的价值在于它把「安装软件」和「链接配置」统一成了同一条命令，但代价是你要接受作者的目录和工具选择。

官方来源

1. Official README
2. Project repository