AI 生成代码时，经常会写出一种看起来很谨慎的风格：到处判断空值、到处给默认值、到处包 try/catch，读取环境变量时还特别喜欢加 trim() 和 fallback。

比如下面这种代码很常见：

const port = Number(process.env.PORT?.trim() || 3000);
const apiKey = process.env.API_KEY?.trim() || "";
const timeout = Number(process.env.TIMEOUT || 5000);
try {
  // do something
} catch (error) {
  console.error(error);
  return null;
}

它表面上很安全：空值兜住了、默认值给了、字符串也 trim 了，异常也 catch 了。但真实工程里，这类写法经常不是让系统更可靠，而是把本该暴露的问题悄悄藏起来。

尤其是读取环境变量时，AI 很容易自动加 trim()、|| default、?? default。因为它把环境变量当成不可信输入来处理，这个判断有一半是对的：环境变量确实来自运行环境，不是代码内部常量。但另一半很危险：不是所有配置都能被自动修正，也不是所有缺失都应该给默认值。

真正的问题不是 AI 写了防御性代码，而是它不知道防御应该放在哪里，哪些错误应该被兜底，哪些错误必须直接暴露。

AI 的局部自保与全局风险

人写代码时，通常知道很多隐藏前提：

• 这个函数只有特定调用方会调用
• 这个参数已经在入口校验过
• 这个字段在数据模型里是必填的
• 这个配置在生产环境一定会存在

AI 往往不知道这些前提。它只能看到局部代码片段，所以会倾向于选择一种局部看起来更稳的写法：多判断一点，多兜底一点，多 catch 一点。

于是它很容易写出这种代码：

if (!user) {
  return null;
}
if (!items?.length) {
  return [];
}
try {
  return await service.run();
} catch {
  return undefined;
}

这些代码在局部看起来不会崩，但在系统层面可能更糟。因为它把本来应该暴露的问题，改造成了一个看似正常的返回值。

比如 return null 可能掩盖了用户不存在、权限不足、数据库异常、调用参数错误等完全不同的问题。调用方拿到 null 以后，不知道该重试、提示用户、回滚事务，还是报警排查。

fail fast 的核心思想是：错误越早、越明确地暴露，越容易定位和修复。系统如果自动绕过错误，问题可能会在更深的链路里变成更隐蔽、更难排查的故障。

所以，AI 的防御性代码经常不是工程健壮，而是局部自保。

为什么 AI 偏爱这种模式？

AI 代码模型学到的不是某个项目的架构约束，而是大量公开代码、教程、问答社区、文档示例里的高频模式。

公开代码里有大量这样的写法：

const value = input || defaultValue;
const name = user?.profile?.name ?? "";
const port = process.env.PORT || 3000;

久而久之，模型会形成一种倾向：不确定时就加默认值，不确定时就加空值判断，不确定时就包一层 try/catch。

但公开代码里也包含大量不安全、过时或不适合生产的写法。AI 生成的代码看起来很防御，不代表它真的安全。它可能只是学会了安全代码的外观，比如加了空值判断、日志和默认值，但没有理解业务契约、权限边界和失败语义。

这也是为什么我们不能只看代码有没有考虑异常，而要看它有没有把异常处理成正确的系统行为。

防御性代码本身没有错，错的是位置不对

真正需要防御的地方，通常是系统边界：

• API 入口（请求参数）
• 外部服务调用（网络、数据库、文件）
• 环境变量读取
• 用户输入表单

这些位置的数据来自外部，确实应该严格校验、解析、归一化和拒绝非法输入。

但在业务核心逻辑里，到处兜底反而会破坏系统契约。

比如这段代码看起来很稳：

async function getUserName(userId?: string) {
  if (!userId) {
    return "";
  }
  const user = await userRepository.findById(userId);
  return user?.name ?? "";
}

调用方拿到空字符串以后，根本不知道发生了什么：userId 没传？用户不存在？数据库挂了？还是用户没有 name 字段？

更好的做法，是把失败语义区分清楚：

type GetUserNameResult =
  | { ok: true; name: string }
  | { ok: false; reason: "USER_NOT_FOUND" };

async function getUserName(userId: string): Promise {
  if (!userId) {
    throw new Error("userId is required");
  }
  const user = await userRepository.findById(userId);
  if (!user) {
    return { ok: false, reason: "USER_NOT_FOUND" };
  }
  return { ok: true, name: user.name };
}

这里的重点不是少写防御代码，而是让每一种失败都有明确含义。参数错误直接抛出，业务上可预期的不存在用结构化结果表达，系统异常交给上层统一处理。

这才是工程上的防御，而不是把所有错误都变成空字符串、null 或 undefined。

环境变量：防御的典型战场

环境变量确实是边界输入。它来自运行环境，不是代码内部定义的常量。

Twelve-Factor App 的配置原则 建议把不同部署之间会变化的配置放到环境变量里，比如数据库连接、外部服务凭证、每个部署不同的主机名等。这样配置可以和代码分离，不同环境也能使用同一份代码。

Node.js 文档也说明，环境变量最终会进入 process.env，并以字符串形式被读取。也就是说，0、true、false、JSON 字符串这些值，在进入应用后都不是数字、布尔值或对象，而是字符串。

所以 AI 看到下面这种代码时：

const port = process.env.PORT;
const enableCache = process.env.ENABLE_CACHE;

它会本能地觉得这里不安全，因为：

• 环境变量可能未定义
• 环境变量可能包含空格（比如复制粘贴时）
• 环境变量是字符串，需要类型转换
• 环境变量可能在不同部署环境（.env、Docker、Kubernetes、CI）下格式不一致

于是它很容易生成：

const port = Number(process.env.PORT?.trim() || 3000);

这里的 trim() 不是完全没道理。它的潜台词是：我先把配置值前后的意外空格去掉，避免部署时因为复制粘贴多了空格导致解析失败。

在某些配置上，这样做是合理的，比如：

const nodeEnv = process.env.NODE_ENV?.trim();
const databaseUrl = process.env.DATABASE_URL?.trim();
const redisUrl = process.env.REDIS_URL?.trim();

但问题是，trim() 不能无脑加。配置值不是普通输入框文本，有些值的空白字符可能本身就是内容的一部分。

对于普通枚举、URL、端口号，去掉前后空格通常没问题。

但对于某些值，空白字符可能就是值的一部分，比如：

• JWT 密钥中的预期空格？很少见，但存在
• Base64 编码的密码里可能包含填充字符
• 某些 Token 格式要求精确匹配

如果 AI 写成这样：

const jwtSecret = process.env.JWT_SECRET?.trim() || "secret";
const privateKey = process.env.PRIVATE_KEY?.trim();

这里至少有两个问题。

第一，trim() 可能改变 secret 的真实值。很多 secret 前后空格不是常见需求，但配置加载器不应该擅自修改它。更稳的做法是：如果不允许前后空格，就校验并报错，而不是悄悄帮它修。

第二，默认值 "secret" 非常危险。生产环境里密钥缺失时，系统应该启动失败，而不是自动使用一个弱默认值继续运行。

更合理的策略，是按配置类型分类处理：

function requireEnv(name: string): string {
  const value = process.env[name];
  if (value === undefined || value === "") {
    throw new Error(`Missing required environment variable: ${name}`);
  }
  return value;
}

function requireTrimmedEnv(name: string): string {
  const value = requireEnv(name);
  const trimmed = value.trim();
  if (trimmed.length === 0) {
    throw new Error(`Environment variable ${name} cannot be blank`);
  }
  return trimmed;
}

function requireSecretEnv(name: string): string {
  const value = requireEnv(name);
  if (value !== value.trim()) {
    throw new Error(
      `Environment variable ${name} contains leading or trailing whitespace`,
    );
  }
  return value;
}

这里的区别很关键：

• 普通字符串：允许 trim，但空值直接抛错
• secret：不自动 trim，发现空格就报错，让运维人员去修复

这才是真正的防御性代码。它不是帮系统圆过去，而是在错误进入业务逻辑之前把它拦下来。

默认值：什么时候该用，什么时候不该用

AI 读取环境变量时，也很喜欢写默认值：

const port = Number(process.env.PORT || 3000);
const databaseUrl = process.env.DATABASE_URL || "postgres://localhost:5432/app";
const jwtSecret = process.env.JWT_SECRET || "secret";
const enableDebug = process.env.ENABLE_DEBUG || false;

这类写法看起来方便，但它把三种完全不同的配置混在了一起：

• 低风险默认值（如端口号）
• 安全敏感配置（如密钥）
• 布尔或数字解析陷阱

比如 PORT 默认成 3000 通常可以接受，因为它不是安全敏感配置。

但 DATABASE_URL、JWT_SECRET、OPENAI_API_KEY、S3_SECRET_KEY 这类配置不能随便默认。缺失就应该启动失败。

否则生产环境可能出现非常隐蔽的问题：

• 数据库连接到了错误的测试数据库
• JWT 签名使用了弱密钥，导致安全漏洞
• API 调用因为密钥不对而失败，但日志里只是显示"空结果"

更好的判断标准是：

可以默认：
- PORT
- LOG_LEVEL
- REQUEST_TIMEOUT_MS
- FEATURE_FLAG 默认关闭
- 分页大小
- 非生产环境 mock 开关

不应该默认：
- DATABASE_URL
- JWT_SECRET
- SESSION_SECRET
- API_KEY
- S3_SECRET_KEY
- ENCRYPTION_KEY
- OAUTH_CLIENT_SECRET
- WEBHOOK_SECRET

默认值不是不能用，而是只能用于缺失也不会破坏安全和数据正确性的配置。

|| default 经常比看起来更危险

AI 很喜欢写：

const timeout = Number(process.env.TIMEOUT_MS) || 5000;

这个写法有一个隐藏问题：它会把所有 falsy 值都当成缺失。

比如：

Number("0") || 5000; // 结果是 5000，不是 0

如果 0 在业务里代表禁用超时、关闭重试、不限制数量，这个默认值就会悄悄改变行为。

更好的写法是先判断是否缺失，再解析：

function optionalIntEnv(name: string, defaultValue: number): number {
  const raw = process.env[name];
  if (raw === undefined || raw.trim() === "") {
    return defaultValue;
  }
  const value = Number(raw);
  if (!Number.isInteger(value)) {
    throw new Error(`Environment variable ${name} must be an integer`);
  }
  return value;
}

const timeoutMs = optionalIntEnv("REQUEST_TIMEOUT_MS", 5000);

这样至少能区分三种情况：

• 变量未设置 → 用默认值
• 变量设置但为空字符串 → 用默认值
• 变量设置且为合法整数 → 使用该值（包括 0）

AI 经常把这三种情况混在一起，所以代码看起来短，实际风险更高。

集中配置管理：让防御发生在正确的地方

环境变量不要散落在业务代码里。

不推荐这样写：

export async function callModel(prompt: string) {
  const apiKey = process.env.OPENAI_API_KEY?.trim() || "";
  if (!apiKey) {
    return null;
  }
  // ...
}

这会带来几个问题：

• 每个文件都可能重复读取环境变量，散落各处
• 部分地方 trim，有的地方不 trim，行为不一致
• 类型不明确，到处是 string | undefined
• 错误处理方式不统一

更推荐在应用启动时集中解析：

type AppConfig = {
  nodeEnv: "development" | "test" | "production";
  port: number;
  databaseUrl: string;
  jwtSecret: string;
  requestTimeoutMs: number;
};

function parseNodeEnv(): AppConfig["nodeEnv"] {
  const value = process.env.NODE_ENV?.trim() || "development";
  if (!["development", "test", "production"].includes(value)) {
    throw new Error(`Invalid NODE_ENV: ${value}`);
  }
  return value as AppConfig["nodeEnv"];
}

function requireTrimmedString(name: string): string {
  const value = process.env[name];
  if (value === undefined) {
    throw new Error(`Missing required environment variable: ${name}`);
  }
  const trimmed = value.trim();
  if (trimmed.length === 0) {
    throw new Error(`Environment variable ${name} cannot be empty`);
  }
  return trimmed;
}

function requireSecret(name: string): string {
  const value = process.env[name];
  if (value === undefined || value.length === 0) {
    throw new Error(`Missing required secret: ${name}`);
  }
  if (value !== value.trim()) {
    throw new Error(`Secret ${name} contains leading or trailing whitespace`);
  }
  return value;
}

function optionalInteger(name: string, defaultValue: number): number {
  const value = process.env[name];
  if (value === undefined || value.trim() === "") {
    return defaultValue;
  }
  const parsed = Number(value);
  if (!Number.isInteger(parsed)) {
    throw new Error(`Environment variable ${name} must be an integer`);
  }
  return parsed;
}

export const config: AppConfig = {
  nodeEnv: parseNodeEnv(),
  port: optionalInteger("PORT", 3000),
  databaseUrl: requireTrimmedString("DATABASE_URL"),
  jwtSecret: requireSecret("JWT_SECRET"),
  requestTimeoutMs: optionalInteger("REQUEST_TIMEOUT_MS", 5000),
};

这个版本看起来比 AI 默认生成的代码更长，但它的工程收益很明确：

• 所有环境变量只在一个模块中读取
• 启动时完成解析和校验，失败即停止
• 每个配置的防御策略独立定义（trim / 不trim / 默认值 / 报错）
• 业务代码只引用 config 对象，不再出现 process.env.xxx

这就是环境变量读取里真正合理的防御性代码。

用 Zod 实现更简洁的校验

如果项目里已经使用 Zod，可以把环境变量当成一个边界输入，用 Schema 统一校验。

import { z } from "zod";

const envSchema = z.object({
  NODE_ENV: z
    .enum(["development", "test", "production"])
    .default("development"),
  PORT: z
    .string()
    .optional()
    .transform((value) => {
      if (value === undefined || value.trim() === "") {
        return 3000;
      }
      const parsed = Number(value);
      if (!Number.isInteger(parsed)) {
        throw new Error("PORT must be an integer");
      }
      return parsed;
    }),
  DATABASE_URL: z
    .string()
    .trim()
    .min(1, "DATABASE_URL is required"),
  JWT_SECRET: z
    .string()
    .min(1, "JWT_SECRET is required")
    .refine((value) => value === value.trim(), {
      message: "JWT_SECRET must not contain leading or trailing whitespace",
    }),
  REQUEST_TIMEOUT_MS: z
    .string()
    .optional()
    .transform((value) => {
      if (value === undefined || value.trim() === "") {
        return 5000;
      }
      const parsed = Number(value);
      if (!Number.isInteger(parsed) || parsed <= 0) {
        throw new Error("REQUEST_TIMEOUT_MS must be a positive integer");
      }
      return parsed;
    }),
});

export const config = envSchema.parse(process.env);

这里不是简单地到处 .trim().default()，而是按配置类型分开处理。

• DATABASE_URL 可以 trim，因为它通常不应该包含前后空格。
• JWT_SECRET 不直接 trim，而是校验是否存在意外空白。因为 secret 是身份和签名边界，系统不应该擅自修改它。

从 AI 的防御性代码中学到什么

环境变量场景正好能说明 AI 防御性代码的核心问题。

AI 加 trim() 的动机是合理的：环境变量是外部输入，确实可能有格式问题。

但它经常不区分：

• 哪些配置可以自动修正（普通字符串）
• 哪些配置不能妥协（secret）
• 哪些配置缺失可以兜底（端口）
• 哪些配置缺失必须 fail fast（数据库 URL）

这就导致它写出一种很圆滑但危险的配置读取代码：

const apiKey = process.env.API_KEY?.trim() || "";
const databaseUrl = process.env.DATABASE_URL?.trim() || "localhost";
const jwtSecret = process.env.JWT_SECRET?.trim() || "secret";

这不是生产级健壮性，而是在用默认值掩盖部署错误。

更好的工程原则是：

环境变量读取可以防御，但不能静默兜底。
普通字符串：可以 trim，但要校验空值。
数字配置：先判断缺失，再解析，再校验范围。
枚举配置：trim 后必须命中允许列表。
URL 配置：trim 后用 URL 解析校验。
secret 配置：不要偷偷 trim，发现意外空白就启动失败。
生产必填配置：不要默认值，缺失就 fail fast。
低风险配置：可以有明确默认值。

如何引导 AI 写出正确的防御代码

以后让 AI 写配置代码时，不要只说"帮我写得健壮一点"。这句话很容易让它到处加兜底。

可以直接这样要求：

请写一个 TypeScript 配置加载模块，要求：
- 所有环境变量只允许在 config 模块中读取
- 应用启动时完成解析和校验
- 必填配置缺失时直接抛错，禁止静默 fallback
- PORT、REQUEST_TIMEOUT_MS 这类低风险配置可以有默认值
- DATABASE_URL、JWT_SECRET、API_KEY、SESSION_SECRET 禁止默认值
- 普通 URL 和枚举值可以 trim
- secret 不要自动 trim，如果出现前后空白应直接报错
- 不要使用 process.env.X || default 这种写法
- 数字配置必须显式 parse，并校验整数、正数和范围
- 输出一个类型明确的 config 对象，业务代码只能使用 config，不直接读 process.env

这样生成的代码会稳定很多，因为你把防御的位置和不能兜底的位置都说清楚了。

总结

AI 喜欢写防御性代码，是因为它面对的是不完整上下文。它不知道哪些错误应该抛出，哪些错误可以恢复，哪些值已经在上游校验过，于是倾向于用空值判断、默认值、trim()、try/catch 来让局部代码看起来更稳。

读取环境变量时，这种倾向会更明显。环境变量确实属于边界输入，需要解析、校验和类型转换。Node.js 中环境变量最终都是字符串，配置又会随着部署环境变化，所以 AI 自动加 trim() 和默认值并不奇怪。

真正的问题是，环境变量不能被粗暴兜底。PORT 可以默认，JWT_SECRET 不能默认；普通 URL 可以 trim，secret 不应该偷偷 trim；非法配置应该启动失败，而不是运行时返回空字符串、null 或弱默认值。

好的防御性代码不是到处兜底，而是：

• 在边界严格校验，不放过任何非法输入
• 在内部明确契约，让失败语义清晰可辨
• 在必要处 fail fast，不让错误在系统深处蔓延

AI 生成代码最需要审查的地方，往往不是它有没有考虑异常，而是它有没有把真正应该暴露的问题悄悄吞掉。