企业官网建设流程全解析

• 开发工具
• CLI

本文以 devenv 1.9 发布的核心能力为主线，讲解如何通过自定义模块（Modules）集中管理团队开发规范，并通过 Profiles（命令行、主机名、用户名三种激活方式）按需组合与覆盖不同的开发环境；读完你将掌握从"零散脚手架"升级为"中央化、可组合、可预测"的 Nix 开发环境治理方案。

为什么需要 Profiles：从脚手架到中央化治理

devenv 一直尝试为语言和服务提供开箱即用的合理默认值（Convention over Configuration），但每个团队都有自己的偏好：有人用 nightly 版 Rust 工具链，有人需要特定的数据库初始化脚本。此前这类"团队最佳实践"通常靠脚手架（scaffold）生成，而脚手架有两个天然缺陷：

• 生成后很快过时，缺少集中推送更新的能力；
• 无法按需激活仓库中某个组件对应的那部分开发环境。

devenv 1.9 引入的Profiles正是为了解决这两个问题：团队可以在一个中央仓库中定义自己的模块（Modules）作为"带倾向性的环境模板"，然后在具体项目中按需激活；同时 Profiles 支持基于主机名、用户名自动激活，从而在保持个人配置简单的条件下实现精细治理。

从源码看，Profiles 功能在 devenv 侧由 devenv/src/cli.rs 的--profile/-P全局参数驱动，其配置模型定义在 src/modules/profiles.nix；CLI 与 Nix 配置的衔接逻辑则在 devenv-core/src/settings.rs（合并 CLI 选项与配置文件中的profile字段）。

扩展 devenv 模块：在中央仓库定义团队规范

团队可以在中央仓库中定义自己的一组推荐实践，创建更有倾向性的环境。核心是使用 Nix 模块系统新增options，然后在config中按开关生效：

{ lib, config, pkgs, ... }: { options.myteam = { languages.rust.enable = lib.mkEnableOption "Rust development stack"; services.database.enable = lib.mkEnableOption "Database services"; }; config = { packages = lib.mkIf config.myteam.languages.rust.enable [ pkgs.cargo-watch ]; languages.rust = lib.mkIf config.myteam.languages.rust.enable { enable = true; channel = "nightly"; }; services.postgres = lib.mkIf config.myteam.services.database.enable { enable = true; initialScript = "CREATE DATABASE myapp;"; }; }; }

这里为myteam.languages.rust与myteam.services.database定义了默认实现：

• lib.mkEnableOption生成的开关默认关闭，需要使用者按项目显式开启；
• lib.mkIf ... [ ... ]保证条件启用，未开启时对应配置不生效；
• 模块的config完全遵循标准 NixOS 模块系统约定，可被下游项目按需覆盖。

这正是 devenv 的模块化架构的体现：devenv 自身所有语言、服务、进程管理器模块均位于 src/modules（例如 src/modules/languages/rust.nix、src/modules/services），团队模块与内置模块使用同一套 options 机制，因此可以在options中继续声明自己的配置项。关于模块系统的更多用法可参考 docs/src/content/docs/extending.md。

使用 Profiles：按项目按需激活团队模块

定义好团队模块后，在devenv.yaml中引入该中央仓库：

inputs: myteam: url: github:myorg/devenv-myteam flake: false imports: - myteam

这样会自动包含你集中管理的模块。由于 options 默认关闭，需要在每个项目中显式开启。可以全局开启通用默认项，再用 Profiles 按需激活附加组件：

{ pkgs, config, ... }: { packages = [ pkgs.jq ]; profiles = { backend.module = { myteam.languages.rust.enable = true; myteam.services.database.enable = true; }; frontend.module = { languages.javascript.enable = true; }; fullstack.extends = [ "backend" "frontend" ]; }; }

• backend.module、frontend.module：module属性是激活该 profile 时合并进来的配置（deferredModule类型，见 src/modules/profiles.nix 第 20-24 行）；
• fullstack.extends = [ "backend" "frontend" ]：通过extends继承多个 profile，形成层级化组合，父 profile 先合并、子 profile 后覆盖，无需mkForce。

命令行激活

用--profile（短参数-P）激活 profile 后运行任意 devenv 子命令：

# 用 backend profile 进入 shell，开始 Rust 开发 $ devenv --profile backend shell # 用 backend profile 启动数据库等进程 $ devenv --profile backend up # 用 frontend profile 进行 JavaScript 开发 $ devenv --profile frontend shell # 用 fullstack profile 同时获得前后端工具（extends 两个 profile） $ devenv --profile fullstack shell

fullstack profile 通过 extends 自动包含 backend 与 frontend 的全部内容。若还需要临时微调，可叠加 ad-hoc 环境选项（见 docs/src/content/docs/ad-hoc-developer-environments.mdx）：

$ devenv -P fullstack -O myteam.languages.rust.enable:bool false shell

CLI 侧的实现细节值得注意（devenv/src/cli.rs）：

• --profile声明为全局参数（global = true），且Vec<String>类型支持一次传入多个 profile；
• 仓库专门实现了参数预处理（preprocess_profile_args），将--profile X转为--profile=X形式，避免 profile 名与子命令重名（如devenv --profile test test）时被 clap 误解，并配有对应的单元测试；
• 多个--profile同时传入时最后一个 flag 生效（优先级最高层）。

用户与主机名 Profiles：基于环境自动激活

Profiles 可以基于主机名或用户名自动激活：

{ profiles = { hostname."dev-server".module = { myteam.services.database.enable = true; }; user."alice".module = { myteam.languages.rust.enable = true; }; }; }

当用户alice在主机名dev-server上运行devenv shell时，她的用户 profile 与主机名 profile 都会自动激活。

配置模型上（src/modules/profiles.nix 第 36-46 行），profiles选项是一个带freeformType的子模块：顶层自由属性为普通手动 profile，而hostname与user两个固定子选项分别承载按主机名、按用户名自动激活的 profile 集合。devenv 启动时会读取当前系统环境（主机名/用户名）完成自动匹配，使团队既能按机器（如 CI 服务器）部署公共工具，也能按个人（如不同角色）叠加个人偏好。

devenv 1.9 同时支持基于"非主机名/用户名"其他条件的自动激活机制，可参考 docs/src/content/docs/auto-activation.mdx。

Profile 优先级：让覆盖顺序确定可预期

为避免 profile 繁多的项目互相"打架"，devenv 将每个 profile 模块包进自动分配的 override 优先级。合并顺序如下：

1. 基础配置（base configuration）最先应用，优先级最低；
2. 主机名 profiles（hostname）叠加其上；
3. 用户 profiles（user）再叠加；
4. 手动--profileflags优先级最高，传入多个时最后一个 flag 生效；
5. extends 链先应用父 profile 再应用子 profile，覆盖落在预期位置。

下面这个例子中每一层都切换同一个选项，最终结果依然确定：

{ config, ... }: { myteam.services.database.enable = false; profiles = { hostname."dev-server".module = { myteam.services.database.enable = true; }; user."alice".module = { myteam.services.database.enable = false; }; qa.module = { myteam.services.database.enable = true; }; }; }

Alice 在dev-server上执行devenv --profile qa shell时，生效链路为：基础配置关闭数据库 → 主机名 profile 开启 → 用户 profile 再次关闭 → 手动qaprofile 重新开启，最终值为true。即使各层赋值冲突，优先级也能让结果可预测，且不会产生 merge 冲突。

该优先级语义在 devenv 核心中有明确实现：CLI 传入的profiles与devenv.nix/devenv.yaml中的profile配置在 devenv-core/src/settings.rs 中合并（options.profiles.combine(config_profiles)），并有对应的优先级合并测试；同时活跃 profile 会作为active_profiles传入 Nix 求值（见 devenv-core/src/nix_args.rs 中active_profiles: &'a [String]字段及其序列化测试），确保 Nix 侧按同一份 profile 列表求值。

在 Profile 内部引用 config：使用函数形式

每个 profile 是一个会被递归合并进顶层配置的子模块。当 profile 内部需要引用由它自己设置的配置值时，必须把module写成接收自身config参数的函数形式。

下面这个例子不会按预期工作：

{ config, ... }: { profiles.dev.module = { # 这里引用的是顶层 config，尚未包含本 profile 设置的 postgres 配置， # PGHOST 是由 postgres 服务设置的环境变量。 env.DB_HOST = config.env.PGHOST; services.postgres.enable = true; }; }

这里的config指向顶层配置，感知不到 profile 内部设置的值。

正确做法是让 profile 模块成为一个函数：

{ config, ... }: { profiles.dev.module = { config, ... }: { # 现在 config 同时包含顶层值与 profile 自身值 env.DB_HOST = config.env.PGHOST; services.postgres.enable = true; }; }

内部config参数包含顶层配置与 profile 自身设置的合并结果。规则总结：

• 当 profile 需要引用同一 profile 内设置的config值时，使用函数形式；
• 只设置静态值、或只读取顶层配置的 profile，可以用简写属性集形式。

组合激活：多个维度同时生效

所有匹配的 profile 都会在运行 devenv 命令时自动合并：

{ languages.nix.enable = true; profiles = { backend.module = { services.postgres.enable = true; }; hostname."ci-server".module = { env.CI = "true"; packages = [ pkgs.buildkit ]; }; user."developer".module = { git.enable = true; packages = [ pkgs.gh ]; }; }; }

当用户 "developer" 在名为 "ci-server" 的机器上运行devenv --profile backend shell时，以下 profile 同时激活并合并：

• 基础配置（始终激活）；
• profiles.backend（通过--profile手动激活）；
• profiles.hostname."ci-server"（主机名自动匹配）；
• profiles.user."developer"（用户名自动匹配）。

devenv 还会为不同 profile 组合隔离运行时状态目录（devenv/src/devenv/mod.rs 的compute_profile_dir_suffix会按排序后的 profile 名生成目录后缀，路径处理与隔离测试见 devenv-core/src/paths.rs），因此同一项目在不同 profile 下可以保持各自的进程、缓存与状态。

其他亮点：macOS 上构建 Linux 容器

devenv 1.9 同时移除了此前在 macOS 上构建容器的限制：只要配置了 Linux builder，就能在 macOS 上构建 Linux 容器（对应 containers.nix 相关能力，完整说明见 docs/src/content/docs/containers.mdx）。容器模块自 devenv 0.6 引入以来积累了大量实践经验，官方也预告容器部分将迎来一次简化重设计。

快速上手

• 刚接触 devenv？先阅读 docs/src/content/docs/getting-started.mdx 学习基础；
• Profiles 的完整示例（含 profile 内部config引用、extends 继承、hostname/user 自动激活与多 profile 组合）见 docs/src/content/docs/profiles.mdx；
• 多组件仓库（monorepo）中如何使用 profiles 与 imports 组织环境，可参考 docs/src/content/docs/composing-using-imports.mdx；
• 团队模块的声明式扩展机制详见 docs/src/content/docs/extending.md。

总结

devenv 1.9 的 Modules + Profiles 组合为规模化 Nix 项目提供了一条清晰路径：Modules 让团队把最佳实践沉淀为中央仓库中的可复用 Nix 模块，Profiles 则通过命令行、主机名、用户名三种激活方式与确定性的优先级顺序，把"全局默认 + 按需组合 + 个人覆盖"落到了可预测的配置合并之中。这套机制既能保持个人与 CI 环境配置的简洁，又能让团队治理集中在单一来源，是从脚手架时代迈向中央化环境治理的关键一步。

• 开发工具
• CLI