Nix 入门指南：声明式包管理
Nix 跨 Linux/macOS/WSL 的声明式包管理器：纯函数式设计、可复现构建、原子升级回滚、多版本共存。本文从哲学差异讲到安装、包管理与开发环境实战。
直接回答：Nix 是纯函数声明式的包管理器——每个包连同完整依赖装进 /nix/store 的唯一哈希路径，多版本独立存储，PATH 与运行期集成仍需管理；环境由声明与锁定输入生成；profile 可回滚到保留的代，但不保证任意构建逐位一致，也不回滚应用数据。跨 Linux、macOS、WSL，日常用户操作可无需 sudo，但多用户安装、daemon 和 /nix 建立通常需要管理员权限。
哲学差异：声明式与隔离
传统包管理把文件铺进共享系统目录——版本冲突、卸载残留是常态。Nix 把每次安装视为纯函数的输出：固定输入有助于复现，但构建时间、随机性、平台与网络访问仍可能影响字节一致性，产物之间互不干扰。这就是"可复现"与"原子回滚"的来源。
安装
# 按官方安装页选择当前系统支持的安装方式，先审查脚本与权限要求
具体 macOS/Linux/WSL2 支持版本及安装模式应按当前官方要求核对，安装后新开 shell 生效。
包管理
nix profile add nixpkgs#git # 安装
nix profile list # 列出
nix profile remove git # 移除
nix profile rollback # 回滚到上一代
上述新 CLI/flake 引用需按所用 Nix 版本启用 nix-command/flakes；生产团队固定 nixpkgs 输入，而不是依赖可变注册表。
每次变更生成新"代"（generation）——后悔药是系统级能力。
开发环境
nix-shell -p nodejs_20 go_1_22 # 临时 shell 含指定工具
团队项目用 flake.nix 或 devbox 封装固化依赖——同一仓库任何机器得到同一环境。
常见问题（FAQ）
Q：Nix 和系统自带包管理冲突吗？
A：不冲突。包存储主要位于 /nix，但安装可能配置 daemon、挂载与 shell 初始化。卸载必须按实际安装器官方步骤处理，不能直接删除 /nix。
Q：磁盘占用会不会失控？
A：多版本共存确实费盘。先检查保留策略；nix-collect-garbage -d 会删除旧代并失去对应回滚能力，磁盘占用可控。
Q：值得个人用户折腾吗？
A：单机单项目用处有限；多机同步环境、团队统一工具链、CI 一致性诉求强的场景，回报立竿见影。
官方参考
本文依据官方文档整理，示例未在本文中进行运行验证。生产部署需按所用版本、权限和实际负载验证。
