Turborepo 环境变量陷阱全解析Langfuse 单仓中的哈希、缓存与 .env 配置实战【免费下载链接】langfuse Open source AI engineering platform: LLM evals, observability, metrics, prompt management, playground, datasets. Integrates with OpenTelemetry, LangChain, OpenAI SDK, LiteLLM, and more. YC W23项目地址: https://gitcode.com/GitHub_Trending/la/langfuseTurborepo 将环境变量分为影响任务哈希与仅运行时可用两类两者的边界模糊往往是缓存失效与脏缓存问题的根源。本文以 Langfuse 仓库内.agents/skills/turborepo/references/environment/gotchas.md的实战经验为主线逐条拆解.env文件、CI 变量、passThroughEnv与运行时变量的常见陷阱并对照 Langfuse 真实的 turbo.json 与 web/src/env.mjs 给出可落地的配置方案与排查手段。先理解环境变量如何进入 Turbo 的哈希Turborepo 为每个任务计算一个任务哈希task hash哈希输入包括包内源码文件、inputs中声明的文件、env/globalEnv中声明的环境变量值、依赖图关系等。缓存命中即意味着输入没变、输出可直接复用。因此凡是在构建过程中会改变输出的变量与文件都必须进入哈希凡是只影响运行时、不改变构建产物的变量才适合放行但不参与哈希。Turbo 本身并不读取.env文件——加载.env的是你的框架Next.js、Vite 等或dotenv。这意味着两层职责分离运行时加载由框架完成例如 Langfuse 的 web/src/env.mjs 通过t3-oss/env-nextjs的createEnv在启动/构建时用 Zod 校验DATABASE_URL、SENTRY_AUTH_TOKEN等变量变更感知由 Turbo 完成即这些.env文件的内容变化必须触发对应任务重新构建。若只做前者不做后者就会踩中本文的第一个陷阱。陷阱一.env文件必须进入inputsTurbo 不知道.env文件的存在也就不会把它们的修改计入哈希。错误写法——只声明变量、不声明文件{ tasks: { build: { env: [DATABASE_URL] } } }这里的env只表示把DATABASE_URL的值纳入哈希。如果该变量的值来自.env文件而文件本身不在inputs中那么你修改.env后哈希不会变化Turbo 可能直接命中旧缓存把带着旧配置的构建产物当作结果回放。正确写法——变量与文件同时纳入哈希{ tasks: { build: { env: [DATABASE_URL], inputs: [$TURBO_DEFAULT$, .env, .env.local, .env.production] } } }要点$TURBO_DEFAULT$必须保留它代表包内默认全部文件这一内置行为缺失它会替换而非扩展默认输入集详见 配置陷阱文档 中Overwriting Default Inputs一节另一种做法是用仓库级globalDependencies声明根目录.env让它在全局哈希中生效影响所有任务。Langfuse 的真实选择Langfuse 在根 turbo.json 中采用globalDependencies: [.env]把根级.env折叠进全局哈希同时使用envMode: loose见下文陷阱二的对照并针对build任务单独声明env: [NEXT_IGNORE_BUILD_ERRORS]代码注释明确说明原因NEXT_IGNORE_BUILD_ERRORStoggles the Next.js type check, so builds with and without it must not share a cache entry — a cached unchecked build would otherwise replay as a type-checked one.这正是决定构建输出的变量必须进哈希的教科书式应用一个开关变量若被漏掉就会产生未做类型检查的缓存产物被当作已检查产物复用的脏缓存。陷阱二严格模式会过滤 CI 变量Turborepo 默认envMode: strict严格模式任务只能看到env、globalEnv、passThroughEnv、globalPassThroughEnv中明确列出的变量未列出的系统变量会被过滤。症状CI 中任务报 authentication required 或 permission denied——因为GITHUB_TOKEN、GITLAB_CI等 CI 提供方变量默认不可见。解决方案把 CI 变量显式放入globalPassThroughEnv{ globalPassThroughEnv: [GITHUB_TOKEN, GITLAB_CI, CI] }Langfuse 仓库则走了另一条路线在 turbo.json 中设置envMode: loose宽松模式即所有系统环境变量对任务可见、但只有env/globalEnv中列出的才参与哈希。宽松模式适合迁移遗留项目或排查严格模式问题代价是需要自行保证缓存正确性否则会出现未哈希变量变了、缓存却恢复了旧结果的机器环境差异问题。两种模式的完整行为对比可参考 环境模式文档。此外Turbo 会对常见框架做环境变量推断如 Next.js 的NEXT_PUBLIC_*、Vite 的VITE_*这些推断变量默认也参与哈希若希望完全显式控制可用env: [!NEXT_PUBLIC_*]排除。陷阱三passThroughEnv不参与哈希变更不会触发重建passThroughEnv中的变量运行时可用但其值变化不会使任务重新执行。这是设计如此——它们被用于不影响输出的场合但也是最容易引发脏缓存的配置。危险示例{ tasks: { build: { passThroughEnv: [API_URL] } } }如果API_URL从 staging 切到 production 发生变化Turbo 可能直接命中缓存把指向错误 API 的构建产物原样返回。passThroughEnv只应用于不影响输出的认证令牌如SENTRY_AUTH_TOKENCI 元数据如GITHUB_RUN_ID构建之后才被消费的变量如部署凭据。Langfuse 对SENTRY_AUTH_TOKEN的处理正符合这一原则该变量仅在 web/next.config.mjs 中用于构建时上传 source mapauthToken: env.SENTRY_AUTH_TOKEN它不改变Next.js 的产物内容因此不必进入env哈希——放入passThroughEnv即可避免换令牌导致全量重建。而DATABASE_URL这类会改变产物行为的变量则必须进入env/globalEnv。对照 Langfuse 的globalEnvturbo.json 中声明了NEXT_PUBLIC_LANGFUSE_BLOB_EXPORT_CUTOFF、NEXT_PUBLIC_LANGFUSE_BLOB_EXPORTER_CUTOFF、NEXT_PUBLIC_LANGFUSE_ANALYTICS_EXPORTER_CUTOFF与CLICKHOUSE_BIN为全局环境变量。这些变量一旦变化所有任务的哈希都会失效——它们与 web/src/env.mjs 中client段的NEXT_PUBLIC_*定义一一对应是会被打进浏览器端产物的编译期常量属于典型的必须进哈希变量。陷阱四运行时创建的环境变量不可见Turbo 在启动时捕获环境变量快照任务执行过程中动态创建的变量它看不到。无效写法在 package.json 脚本里临时导出再构建{ scripts: { build: export API_URL$COMPUTED_VALUE next build } }正确做法在调用 turbo 之前完成赋值API_URL$COMPUTED_VALUE turbo run build这样API_URL才能被 Turbo 捕获并依据你的env配置决定是否进入哈希。同理若某变量由 shell 展开、文件读取等方式在进程内生成务必在进程启动前注入而不是依赖任务内部的副作用。陷阱五多环境的.env文件要成套进inputs如果你使用.env.development和.env.production两者都应列入inputs否则某个环境独有的配置变更不会触发对应任务重建{ tasks: { build: { inputs: [ $TURBO_DEFAULT$, .env, .env.local, .env.development, .env.development.local, .env.production, .env.production.local ] } } }注意这套做法覆盖的是构建期读到的.env。对于 Docker 部署等场景web/src/env.mjs 的注释特别提醒NEXT_PUBLIC_前缀变量是编译期内联而非运行时读取Docker 镜像构建时若依赖这类变量需要保证构建阶段就传入正确的值。完整 Next.js 示例官方推荐写法{ $schema: https://v2-8-21-canary-9.turborepo.dev/schema.json, globalEnv: [CI, NODE_ENV, VERCEL], globalPassThroughEnv: [GITHUB_TOKEN, VERCEL_URL], tasks: { build: { dependsOn: [^build], env: [DATABASE_URL, NEXT_PUBLIC_*, !NEXT_PUBLIC_ANALYTICS_ID], passThroughEnv: [SENTRY_AUTH_TOKEN], inputs: [ $TURBO_DEFAULT$, .env, .env.local, .env.production, .env.production.local ], outputs: [.next/**, !.next/cache/**] } } }这段配置的行为DATABASE_URL与NEXT_PUBLIC_*除 analytics 外进入任务哈希SENTRY_AUTH_TOKEN仅透传、不参与哈希全部.env变体文件纳入哈希CI 令牌GITHUB_TOKEN全局可见产物声明为.next/**并排除缓存目录避免把 Next.js 自身缓存当作任务产物。其中env: [NEXT_PUBLIC_*, !NEXT_PUBLIC_ANALYTICS_ID]展示了通配符 否定的组合批量纳入前缀变量、再精确剔除与分析 ID 相关的变量防止埋点 ID 变化引发无意义重建通配符与否定语法详见 环境变量规则文档。进阶futureFlags.globalConfiguration下的新写法启用futureFlags.globalConfiguration后全局配置统一收拢到global键下且语义发生变化.env文件从折叠进全局哈希改为作为隐式任务输入逐任务单独进入哈希。{ $schema: https://v2-8-21-canary-9.turborepo.dev/schema.json, futureFlags: { globalConfiguration: true }, global: { env: [CI, NODE_ENV, VERCEL], passThroughEnv: [GITHUB_TOKEN, VERCEL_URL], inputs: [.env, .env.local, .env.production, .env.production.local] }, tasks: { build: { dependsOn: [^build], env: [DATABASE_URL, NEXT_PUBLIC_*, !NEXT_PUBLIC_ANALYTICS_ID], passThroughEnv: [SENTRY_AUTH_TOKEN], outputs: [.next/**, !.next/cache/**] } } }新旧键名对照旧顶层新global.globalDependenciesinputsglobalEnvenvglobalPassThroughEnvpassThroughEnv行为差异是关键旧写法globalDependencies会把文件哈希进全局哈希任何任务都无法豁免新写法global.inputs是逐任务前置的隐式输入任务可以用否定 glob 排除特定文件。例如不关心.env.production的 lint 任务可以这样豁免lint: { inputs: [$TURBO_DEFAULT$, !$TURBO_ROOT$/.env.production] }这是旧globalDependencies时代做不到的精细控制。但要注意 配置陷阱文档 中强调的反例排除全局输入时必须保留$TURBO_DEFAULT$否则任务会因没有包含 glob而哈希空集——源文件怎么改都不会触发缓存失效。如何在 Langfuse 中验证与调试环境变量配置Langfuse 仓库本身提供了可对照的真实样例根 package.json 只做委托build: turbo run build、dev: turbo run dev、test: turbo run test任务逻辑全部下沉到各包turbo 版本锁定为2.10.5根 turbo.json 注册任务管线build/typecheck/lint声明dependsOn: [db:generate, ^build]dev系列任务声明cache: false, persistent: truedb:*系列全部cache: false避免缓存副作用型任务并给出langfuse/shared#db:generate这类包级任务覆盖的写法web/src/env.mjs 是运行时校验层服务端DATABASE_URL: z.url()、SENTRY_AUTH_TOKEN可选字符串、ENCRYPTION_KEY强制 64 位十六进制等均通过 Zod 在启动时把关web/next.config.mjs 在文件顶部await import(./src/env.mjs)构建期即读取环境变量如 CSP、NEXT_PUBLIC_ASSET_PREFIX、Sentry source map 上传印证构建输出依赖的变量必须进哈希的结论。排查环境变量问题时可参考 缓存调试指南 提供的三件套# 1. 查看每个任务实际纳入哈希的环境变量 turbo run build --dryjson | jq .tasks[].environmentVariables # 2. 生成含全部哈希输入的 JSON 摘要对比两次运行找出差异 turbo run build --summarize diff .turbo/runs/first-run.json .turbo/runs/second-run.json # 3. 跳过缓存强制重跑验证任务本身可用 turbo run build --force小结一张自检清单对照本文五个陷阱配置任何 Turborepo 任务前请自查任务读取的.env含各环境变体是否已进inputs/globalDependencies或global.inputs严格模式下 CI 令牌等系统变量是否已通过globalPassThroughEnv放行Langfuse 则用envMode: loose换取迁移便利须自行承担哈希正确性放进passThroughEnv的变量是否真的不影响构建产物——SENTRY_AUTH_TOKEN这类可以API_URL这类绝对不行动态生成的变量是否在turbo run启动前注入而非在任务内部 export所有会影响输出的变量是否都已列入env/globalEnv需要排除的前缀变量是否用!否定精确剔除使用global.inputs排除文件时是否保留了$TURBO_DEFAULT$。遵循这六点就能同时规避该重建却没重建的脏缓存与不该重建却全量重跑的性能浪费——这也是 Langfuse 在 turbo.json 中注释所体现的工程准则缓存正确性优先任何影响输出的输入都必须显式、完整地进入哈希。【免费下载链接】langfuse Open source AI engineering platform: LLM evals, observability, metrics, prompt management, playground, datasets. Integrates with OpenTelemetry, LangChain, OpenAI SDK, LiteLLM, and more. YC W23项目地址: https://gitcode.com/GitHub_Trending/la/langfuse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Turborepo 环境变量陷阱全解析：Langfuse 单仓中的哈希、缓存与 .env 配置实战
Turborepo 环境变量陷阱全解析Langfuse 单仓中的哈希、缓存与 .env 配置实战【免费下载链接】langfuse Open source AI engineering platform: LLM evals, observability, metrics, prompt management, playground, datasets. Integrates with OpenTelemetry, LangChain, OpenAI SDK, LiteLLM, and more. YC W23项目地址: https://gitcode.com/GitHub_Trending/la/langfuseTurborepo 将环境变量分为影响任务哈希与仅运行时可用两类两者的边界模糊往往是缓存失效与脏缓存问题的根源。本文以 Langfuse 仓库内.agents/skills/turborepo/references/environment/gotchas.md的实战经验为主线逐条拆解.env文件、CI 变量、passThroughEnv与运行时变量的常见陷阱并对照 Langfuse 真实的 turbo.json 与 web/src/env.mjs 给出可落地的配置方案与排查手段。先理解环境变量如何进入 Turbo 的哈希Turborepo 为每个任务计算一个任务哈希task hash哈希输入包括包内源码文件、inputs中声明的文件、env/globalEnv中声明的环境变量值、依赖图关系等。缓存命中即意味着输入没变、输出可直接复用。因此凡是在构建过程中会改变输出的变量与文件都必须进入哈希凡是只影响运行时、不改变构建产物的变量才适合放行但不参与哈希。Turbo 本身并不读取.env文件——加载.env的是你的框架Next.js、Vite 等或dotenv。这意味着两层职责分离运行时加载由框架完成例如 Langfuse 的 web/src/env.mjs 通过t3-oss/env-nextjs的createEnv在启动/构建时用 Zod 校验DATABASE_URL、SENTRY_AUTH_TOKEN等变量变更感知由 Turbo 完成即这些.env文件的内容变化必须触发对应任务重新构建。若只做前者不做后者就会踩中本文的第一个陷阱。陷阱一.env文件必须进入inputsTurbo 不知道.env文件的存在也就不会把它们的修改计入哈希。错误写法——只声明变量、不声明文件{ tasks: { build: { env: [DATABASE_URL] } } }这里的env只表示把DATABASE_URL的值纳入哈希。如果该变量的值来自.env文件而文件本身不在inputs中那么你修改.env后哈希不会变化Turbo 可能直接命中旧缓存把带着旧配置的构建产物当作结果回放。正确写法——变量与文件同时纳入哈希{ tasks: { build: { env: [DATABASE_URL], inputs: [$TURBO_DEFAULT$, .env, .env.local, .env.production] } } }要点$TURBO_DEFAULT$必须保留它代表包内默认全部文件这一内置行为缺失它会替换而非扩展默认输入集详见 配置陷阱文档 中Overwriting Default Inputs一节另一种做法是用仓库级globalDependencies声明根目录.env让它在全局哈希中生效影响所有任务。Langfuse 的真实选择Langfuse 在根 turbo.json 中采用globalDependencies: [.env]把根级.env折叠进全局哈希同时使用envMode: loose见下文陷阱二的对照并针对build任务单独声明env: [NEXT_IGNORE_BUILD_ERRORS]代码注释明确说明原因NEXT_IGNORE_BUILD_ERRORStoggles the Next.js type check, so builds with and without it must not share a cache entry — a cached unchecked build would otherwise replay as a type-checked one.这正是决定构建输出的变量必须进哈希的教科书式应用一个开关变量若被漏掉就会产生未做类型检查的缓存产物被当作已检查产物复用的脏缓存。陷阱二严格模式会过滤 CI 变量Turborepo 默认envMode: strict严格模式任务只能看到env、globalEnv、passThroughEnv、globalPassThroughEnv中明确列出的变量未列出的系统变量会被过滤。症状CI 中任务报 authentication required 或 permission denied——因为GITHUB_TOKEN、GITLAB_CI等 CI 提供方变量默认不可见。解决方案把 CI 变量显式放入globalPassThroughEnv{ globalPassThroughEnv: [GITHUB_TOKEN, GITLAB_CI, CI] }Langfuse 仓库则走了另一条路线在 turbo.json 中设置envMode: loose宽松模式即所有系统环境变量对任务可见、但只有env/globalEnv中列出的才参与哈希。宽松模式适合迁移遗留项目或排查严格模式问题代价是需要自行保证缓存正确性否则会出现未哈希变量变了、缓存却恢复了旧结果的机器环境差异问题。两种模式的完整行为对比可参考 环境模式文档。此外Turbo 会对常见框架做环境变量推断如 Next.js 的NEXT_PUBLIC_*、Vite 的VITE_*这些推断变量默认也参与哈希若希望完全显式控制可用env: [!NEXT_PUBLIC_*]排除。陷阱三passThroughEnv不参与哈希变更不会触发重建passThroughEnv中的变量运行时可用但其值变化不会使任务重新执行。这是设计如此——它们被用于不影响输出的场合但也是最容易引发脏缓存的配置。危险示例{ tasks: { build: { passThroughEnv: [API_URL] } } }如果API_URL从 staging 切到 production 发生变化Turbo 可能直接命中缓存把指向错误 API 的构建产物原样返回。passThroughEnv只应用于不影响输出的认证令牌如SENTRY_AUTH_TOKENCI 元数据如GITHUB_RUN_ID构建之后才被消费的变量如部署凭据。Langfuse 对SENTRY_AUTH_TOKEN的处理正符合这一原则该变量仅在 web/next.config.mjs 中用于构建时上传 source mapauthToken: env.SENTRY_AUTH_TOKEN它不改变Next.js 的产物内容因此不必进入env哈希——放入passThroughEnv即可避免换令牌导致全量重建。而DATABASE_URL这类会改变产物行为的变量则必须进入env/globalEnv。对照 Langfuse 的globalEnvturbo.json 中声明了NEXT_PUBLIC_LANGFUSE_BLOB_EXPORT_CUTOFF、NEXT_PUBLIC_LANGFUSE_BLOB_EXPORTER_CUTOFF、NEXT_PUBLIC_LANGFUSE_ANALYTICS_EXPORTER_CUTOFF与CLICKHOUSE_BIN为全局环境变量。这些变量一旦变化所有任务的哈希都会失效——它们与 web/src/env.mjs 中client段的NEXT_PUBLIC_*定义一一对应是会被打进浏览器端产物的编译期常量属于典型的必须进哈希变量。陷阱四运行时创建的环境变量不可见Turbo 在启动时捕获环境变量快照任务执行过程中动态创建的变量它看不到。无效写法在 package.json 脚本里临时导出再构建{ scripts: { build: export API_URL$COMPUTED_VALUE next build } }正确做法在调用 turbo 之前完成赋值API_URL$COMPUTED_VALUE turbo run build这样API_URL才能被 Turbo 捕获并依据你的env配置决定是否进入哈希。同理若某变量由 shell 展开、文件读取等方式在进程内生成务必在进程启动前注入而不是依赖任务内部的副作用。陷阱五多环境的.env文件要成套进inputs如果你使用.env.development和.env.production两者都应列入inputs否则某个环境独有的配置变更不会触发对应任务重建{ tasks: { build: { inputs: [ $TURBO_DEFAULT$, .env, .env.local, .env.development, .env.development.local, .env.production, .env.production.local ] } } }注意这套做法覆盖的是构建期读到的.env。对于 Docker 部署等场景web/src/env.mjs 的注释特别提醒NEXT_PUBLIC_前缀变量是编译期内联而非运行时读取Docker 镜像构建时若依赖这类变量需要保证构建阶段就传入正确的值。完整 Next.js 示例官方推荐写法{ $schema: https://v2-8-21-canary-9.turborepo.dev/schema.json, globalEnv: [CI, NODE_ENV, VERCEL], globalPassThroughEnv: [GITHUB_TOKEN, VERCEL_URL], tasks: { build: { dependsOn: [^build], env: [DATABASE_URL, NEXT_PUBLIC_*, !NEXT_PUBLIC_ANALYTICS_ID], passThroughEnv: [SENTRY_AUTH_TOKEN], inputs: [ $TURBO_DEFAULT$, .env, .env.local, .env.production, .env.production.local ], outputs: [.next/**, !.next/cache/**] } } }这段配置的行为DATABASE_URL与NEXT_PUBLIC_*除 analytics 外进入任务哈希SENTRY_AUTH_TOKEN仅透传、不参与哈希全部.env变体文件纳入哈希CI 令牌GITHUB_TOKEN全局可见产物声明为.next/**并排除缓存目录避免把 Next.js 自身缓存当作任务产物。其中env: [NEXT_PUBLIC_*, !NEXT_PUBLIC_ANALYTICS_ID]展示了通配符 否定的组合批量纳入前缀变量、再精确剔除与分析 ID 相关的变量防止埋点 ID 变化引发无意义重建通配符与否定语法详见 环境变量规则文档。进阶futureFlags.globalConfiguration下的新写法启用futureFlags.globalConfiguration后全局配置统一收拢到global键下且语义发生变化.env文件从折叠进全局哈希改为作为隐式任务输入逐任务单独进入哈希。{ $schema: https://v2-8-21-canary-9.turborepo.dev/schema.json, futureFlags: { globalConfiguration: true }, global: { env: [CI, NODE_ENV, VERCEL], passThroughEnv: [GITHUB_TOKEN, VERCEL_URL], inputs: [.env, .env.local, .env.production, .env.production.local] }, tasks: { build: { dependsOn: [^build], env: [DATABASE_URL, NEXT_PUBLIC_*, !NEXT_PUBLIC_ANALYTICS_ID], passThroughEnv: [SENTRY_AUTH_TOKEN], outputs: [.next/**, !.next/cache/**] } } }新旧键名对照旧顶层新global.globalDependenciesinputsglobalEnvenvglobalPassThroughEnvpassThroughEnv行为差异是关键旧写法globalDependencies会把文件哈希进全局哈希任何任务都无法豁免新写法global.inputs是逐任务前置的隐式输入任务可以用否定 glob 排除特定文件。例如不关心.env.production的 lint 任务可以这样豁免lint: { inputs: [$TURBO_DEFAULT$, !$TURBO_ROOT$/.env.production] }这是旧globalDependencies时代做不到的精细控制。但要注意 配置陷阱文档 中强调的反例排除全局输入时必须保留$TURBO_DEFAULT$否则任务会因没有包含 glob而哈希空集——源文件怎么改都不会触发缓存失效。如何在 Langfuse 中验证与调试环境变量配置Langfuse 仓库本身提供了可对照的真实样例根 package.json 只做委托build: turbo run build、dev: turbo run dev、test: turbo run test任务逻辑全部下沉到各包turbo 版本锁定为2.10.5根 turbo.json 注册任务管线build/typecheck/lint声明dependsOn: [db:generate, ^build]dev系列任务声明cache: false, persistent: truedb:*系列全部cache: false避免缓存副作用型任务并给出langfuse/shared#db:generate这类包级任务覆盖的写法web/src/env.mjs 是运行时校验层服务端DATABASE_URL: z.url()、SENTRY_AUTH_TOKEN可选字符串、ENCRYPTION_KEY强制 64 位十六进制等均通过 Zod 在启动时把关web/next.config.mjs 在文件顶部await import(./src/env.mjs)构建期即读取环境变量如 CSP、NEXT_PUBLIC_ASSET_PREFIX、Sentry source map 上传印证构建输出依赖的变量必须进哈希的结论。排查环境变量问题时可参考 缓存调试指南 提供的三件套# 1. 查看每个任务实际纳入哈希的环境变量 turbo run build --dryjson | jq .tasks[].environmentVariables # 2. 生成含全部哈希输入的 JSON 摘要对比两次运行找出差异 turbo run build --summarize diff .turbo/runs/first-run.json .turbo/runs/second-run.json # 3. 跳过缓存强制重跑验证任务本身可用 turbo run build --force小结一张自检清单对照本文五个陷阱配置任何 Turborepo 任务前请自查任务读取的.env含各环境变体是否已进inputs/globalDependencies或global.inputs严格模式下 CI 令牌等系统变量是否已通过globalPassThroughEnv放行Langfuse 则用envMode: loose换取迁移便利须自行承担哈希正确性放进passThroughEnv的变量是否真的不影响构建产物——SENTRY_AUTH_TOKEN这类可以API_URL这类绝对不行动态生成的变量是否在turbo run启动前注入而非在任务内部 export所有会影响输出的变量是否都已列入env/globalEnv需要排除的前缀变量是否用!否定精确剔除使用global.inputs排除文件时是否保留了$TURBO_DEFAULT$。遵循这六点就能同时规避该重建却没重建的脏缓存与不该重建却全量重跑的性能浪费——这也是 Langfuse 在 turbo.json 中注释所体现的工程准则缓存正确性优先任何影响输出的输入都必须显式、完整地进入哈希。【免费下载链接】langfuse Open source AI engineering platform: LLM evals, observability, metrics, prompt management, playground, datasets. Integrates with OpenTelemetry, LangChain, OpenAI SDK, LiteLLM, and more. YC W23项目地址: https://gitcode.com/GitHub_Trending/la/langfuse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
