PostHog 本地开发中找不到某个环境变量从哪里来的怎么定位【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog在 PostHog 本地开发中有一类很常见的困惑某个环境变量明明在你的 shell 里已经生效比如echo $DEBUG有输出但把仓库里所有.env*文件都 grep 一遍却找不到它的定义。这时它大概率不是来自 dotenv而是来自flox这一层。本文给出一条可直接执行的定位路径先确认各层优先级再逐层排查最后用flox activate验证实际解析值。适用前提你使用仓库自带的方式做本地开发即 Flox direnv bin/starthogli start。完整环境说明见 developing-locally.md本文的核心事实来自 dev-env-vars.md。先搞清楚本地环境变量的五层来源PostHog 本地环境中一个变量的值按以下优先级从高到低解析优先级来源说明1你的 shell你自己export的变量覆盖下面所有层2flox[vars].flox/env/manifest.toml每次flox activate时注入DEBUG1、CLICKHOUSE_DATABASE这类始终开启的开发项就在这里。它们不在任何.env文件里所以 grep.env*会一无所获3.env.local个人覆盖项与密钥gitignoredop://引用由 1Password 自动解析由bin/start加载4.env.development提交进仓库的 dev 模式运行时配置5.env.services提交进仓库的服务连接默认值与容器共享注入机制上有两个关键事实决定了为什么找不到.envrc 会在你cd进仓库目录时通过 direnv 自动执行flox activate所以 flox[vars]里的变量会随每次进入目录自动出现在 shell 里看起来像凭空出现。bin/start 按.env.local.env.development.env.services的顺序加载这三个 dotenv 文件并且只在变量尚不存在于环境时才设置。因此 flox[vars]和 shell 的 export 天然压过 dotenv 文件。定位某个变量三步排查以下命令直接来自 dev-env-vars.md把FOO换成你要定位的变量名比如DEBUG、CLICKHOUSE_DATABASE即可执行。第一步检查 flox 层最常见的隐形来源# The flox layer (the usual invisible source): grep -n FOO .flox/env/manifest.toml如果命中说明该变量由 flox 环境在每次 activate 时注入。仓库当前 .flox/env/manifest.toml 的[vars]段就有实例DEBUG 1、CLICKHOUSE_DATABASE posthog、FLAGS_REDIS_URL、DOTENV_FILE .env等。第二步检查各 dotenv 层# The dotenv layers: grep -n FOO .env .env.local .env.development .env.services .env.example注意.env和.env.local可能是本地才存在的文件.env由python manage.py setup_background_agents从.env.example追加若干键DEBUG、SANDBOX_PROVIDER等生成.env.local建议从.env.local.example复制得到cp .env.local.example .env.local缺失时bin/start只会用提交进仓库的默认值运行并打印提示。如果.env.local里含op://引用bin/start检测到后会在op run --env-file.env.local下重新执行自身由 1Password 解析——所以值来自 1Password 凭据也是一种在文件里 grep 不到明文的情况文件里只有op://...引用而解析后的真实值不会落盘。第三步确认激活环境实际解析出的值# What the activated env actually resolves to: flox activate -- bash -c echo $FOO这条命令输出激活 flox 环境后$FOO的最终解析值用来核对前两步的定位结论。如果前两步都没命中而这里仍有值说明是你 shell 自己export的shell 层优先级最高回查当前 shell 的配置或会话历史即可。判断下一步命中[vars]想改这个值个人覆盖应写进.env.localgitignored不要改[vars]提交共享配置之外的语义命中.env.local这是你自己的覆盖项直接编辑该文件只命中.env.development/.env.services它们是提交进仓库的默认值同样建议用.env.local覆盖而不是改动它们。典型症状启动报错时错误信息本身会指向来源当环境变量问题表现为启动失败而不是查不到来源时PostHog 的守卫代码会直接把来源告诉你。posthog/settings/utils.py 中的assert_debug_not_in_production会拒绝在CLOUD_DEPLOYMENT为US/EU/DEV时带着DEBUG启动抛出的ImproperlyConfigured信息明确写着DEBUG must not be enabled on deployed cloud environments (CLOUD_DEPLOYMENT...). Unset DEBUG. Developing cloud-only features locally? Use CLOUD_DEPLOYMENTE2E instead — is_cloud() treats it as cloud and it is allowed with DEBUG. (DEBUG1 is injected by the flox env: .flox/env/manifest.toml [vars].)也就是说报错信息直接指出DEBUG1来自 flox manifest 的[vars]。此时文档给出的正确处理方式是# in .env.local CLOUD_DEPLOYMENTE2EE2E被is_cloud()视为 cloud且是唯一允许与DEBUG共存的 cloud 取值。文档特别警告不要用设置CLOUD_DEPLOYMENTUS并 unsetDEBUG来绕过守卫——unsetDEBUG会触发 sandbox-provider 的守卫docker/MODAL_DOCKER要求DEBUG会在两组守卫之间来回碰壁。另外按字面 region 分支的代码get_instance_region()、region US会看到E2E做 region 相关的测试时用override_settings(CLOUD_DEPLOYMENTUS)按测试覆盖即可测试不受该守卫限制。限制与边界flox activate -- bash -c echo $FOO只反映 flox 环境解析后的值不反映你在当前 shell 里手动export的覆盖shell 层命中时要单独排查。.env.local中未解析的op://字符串不会被source_env_defaults当值写入环境脚本会跳过它们只有op run路径会解析没装opCLI 时bin/start会打印警告并跳过这些引用依赖它们的服务会以各自的 missing key 报错。若你用的是 PostHog Desktop 的 sandbox 开发形态provider 相关环境见 sandboxes-setup-guide.md其DEBUG/CLOUD_DEPLOYMENT守卫逻辑与本文一致。【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PostHog 本地开发中找不到某个环境变量从哪里来的怎么定位？
PostHog 本地开发中找不到某个环境变量从哪里来的怎么定位【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog在 PostHog 本地开发中有一类很常见的困惑某个环境变量明明在你的 shell 里已经生效比如echo $DEBUG有输出但把仓库里所有.env*文件都 grep 一遍却找不到它的定义。这时它大概率不是来自 dotenv而是来自flox这一层。本文给出一条可直接执行的定位路径先确认各层优先级再逐层排查最后用flox activate验证实际解析值。适用前提你使用仓库自带的方式做本地开发即 Flox direnv bin/starthogli start。完整环境说明见 developing-locally.md本文的核心事实来自 dev-env-vars.md。先搞清楚本地环境变量的五层来源PostHog 本地环境中一个变量的值按以下优先级从高到低解析优先级来源说明1你的 shell你自己export的变量覆盖下面所有层2flox[vars].flox/env/manifest.toml每次flox activate时注入DEBUG1、CLICKHOUSE_DATABASE这类始终开启的开发项就在这里。它们不在任何.env文件里所以 grep.env*会一无所获3.env.local个人覆盖项与密钥gitignoredop://引用由 1Password 自动解析由bin/start加载4.env.development提交进仓库的 dev 模式运行时配置5.env.services提交进仓库的服务连接默认值与容器共享注入机制上有两个关键事实决定了为什么找不到.envrc 会在你cd进仓库目录时通过 direnv 自动执行flox activate所以 flox[vars]里的变量会随每次进入目录自动出现在 shell 里看起来像凭空出现。bin/start 按.env.local.env.development.env.services的顺序加载这三个 dotenv 文件并且只在变量尚不存在于环境时才设置。因此 flox[vars]和 shell 的 export 天然压过 dotenv 文件。定位某个变量三步排查以下命令直接来自 dev-env-vars.md把FOO换成你要定位的变量名比如DEBUG、CLICKHOUSE_DATABASE即可执行。第一步检查 flox 层最常见的隐形来源# The flox layer (the usual invisible source): grep -n FOO .flox/env/manifest.toml如果命中说明该变量由 flox 环境在每次 activate 时注入。仓库当前 .flox/env/manifest.toml 的[vars]段就有实例DEBUG 1、CLICKHOUSE_DATABASE posthog、FLAGS_REDIS_URL、DOTENV_FILE .env等。第二步检查各 dotenv 层# The dotenv layers: grep -n FOO .env .env.local .env.development .env.services .env.example注意.env和.env.local可能是本地才存在的文件.env由python manage.py setup_background_agents从.env.example追加若干键DEBUG、SANDBOX_PROVIDER等生成.env.local建议从.env.local.example复制得到cp .env.local.example .env.local缺失时bin/start只会用提交进仓库的默认值运行并打印提示。如果.env.local里含op://引用bin/start检测到后会在op run --env-file.env.local下重新执行自身由 1Password 解析——所以值来自 1Password 凭据也是一种在文件里 grep 不到明文的情况文件里只有op://...引用而解析后的真实值不会落盘。第三步确认激活环境实际解析出的值# What the activated env actually resolves to: flox activate -- bash -c echo $FOO这条命令输出激活 flox 环境后$FOO的最终解析值用来核对前两步的定位结论。如果前两步都没命中而这里仍有值说明是你 shell 自己export的shell 层优先级最高回查当前 shell 的配置或会话历史即可。判断下一步命中[vars]想改这个值个人覆盖应写进.env.localgitignored不要改[vars]提交共享配置之外的语义命中.env.local这是你自己的覆盖项直接编辑该文件只命中.env.development/.env.services它们是提交进仓库的默认值同样建议用.env.local覆盖而不是改动它们。典型症状启动报错时错误信息本身会指向来源当环境变量问题表现为启动失败而不是查不到来源时PostHog 的守卫代码会直接把来源告诉你。posthog/settings/utils.py 中的assert_debug_not_in_production会拒绝在CLOUD_DEPLOYMENT为US/EU/DEV时带着DEBUG启动抛出的ImproperlyConfigured信息明确写着DEBUG must not be enabled on deployed cloud environments (CLOUD_DEPLOYMENT...). Unset DEBUG. Developing cloud-only features locally? Use CLOUD_DEPLOYMENTE2E instead — is_cloud() treats it as cloud and it is allowed with DEBUG. (DEBUG1 is injected by the flox env: .flox/env/manifest.toml [vars].)也就是说报错信息直接指出DEBUG1来自 flox manifest 的[vars]。此时文档给出的正确处理方式是# in .env.local CLOUD_DEPLOYMENTE2EE2E被is_cloud()视为 cloud且是唯一允许与DEBUG共存的 cloud 取值。文档特别警告不要用设置CLOUD_DEPLOYMENTUS并 unsetDEBUG来绕过守卫——unsetDEBUG会触发 sandbox-provider 的守卫docker/MODAL_DOCKER要求DEBUG会在两组守卫之间来回碰壁。另外按字面 region 分支的代码get_instance_region()、region US会看到E2E做 region 相关的测试时用override_settings(CLOUD_DEPLOYMENTUS)按测试覆盖即可测试不受该守卫限制。限制与边界flox activate -- bash -c echo $FOO只反映 flox 环境解析后的值不反映你在当前 shell 里手动export的覆盖shell 层命中时要单独排查。.env.local中未解析的op://字符串不会被source_env_defaults当值写入环境脚本会跳过它们只有op run路径会解析没装opCLI 时bin/start会打印警告并跳过这些引用依赖它们的服务会以各自的 missing key 报错。若你用的是 PostHog Desktop 的 sandbox 开发形态provider 相关环境见 sandboxes-setup-guide.md其DEBUG/CLOUD_DEPLOYMENT守卫逻辑与本文一致。【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考