AI 为什么总喜欢写防御性代码？

大家好 👋，我是 Moment，目前正在使用 Next.js、NestJS、LangChain 开发 DocFlow。这是一个面向 AI 场景的协同文档平台，集成了基于 Tiptap 的富文本编辑、NestJS 后端服务、实时协作与智能化工作流等核心模块。

在这个项目的持续打磨过程中，我积累了不少实战经验，不只是 Tiptap 的深度定制、编辑器性能优化和协同方案设计，也包括前端工程化建设、React 源码理解以及复杂项目架构实践。

如果你对 AI 全栈开发、文档编辑器、前端工程化或者 React 源码相关内容感兴趣，欢迎添加我的微信 yunmz777 一起交流。觉得项目还不错的话，也欢迎给 DocFlow 点个 star ⭐

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

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

ini 复制代码

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 写防御性代码，本质是在弥补上下文缺失

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

这个参数是不是已经被 DTO 校验过
这个函数是不是只会在内部调用
这个字段在数据库里是不是非空
这个异常应该由上层统一处理，还是在当前函数里消化
这个配置缺失时应该启动失败，还是可以使用默认值

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

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

kotlin 复制代码

if (!user) {
  return null;
}

if (!items?.length) {
  return [];
}

try {
  return await service.run();
} catch {
  return undefined;
}

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

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

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

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

训练语料也在强化这种写法

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

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

ini 复制代码

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

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

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

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

防御性代码应该出现在边界，而不是到处出现

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

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

HTTP 请求参数
表单输入
上传文件
第三方 API 返回值
Webhook payload
环境变量
CLI 参数
数据导入文件
跨租户资源访问
权限和角色判断

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

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

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

csharp 复制代码

async function getUserName(userId?: string) {
  if (!userId) {
    return "";
  }

  const user = await userRepository.findById(userId);

  return user?.name ?? "";
}

调用方拿到空字符串以后，根本不知道发生了什么：

是 userId 没传？
是用户不存在？
是数据库异常？
是权限不够？
是数据脏了？
是代码调用错了？

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

typescript 复制代码

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

async function getUserName(userId: string): Promise<GetUserNameResult> {
  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。

读取环境变量时，AI 为什么喜欢加 trim

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

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

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

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

ini 复制代码

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

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

值可能不存在
值一定是字符串
值可能包含空格
值可能需要转换成数字、布尔值、URL 或枚举
值可能来自 .env、Docker、Kubernetes、CI 或部署平台

于是它很容易生成：

ini 复制代码

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

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

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

ini 复制代码

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

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

trim 最大的问题，是它可能改变配置语义

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

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

密码
Token
HMAC secret
私钥
多行证书
Base64 内容
某些第三方平台生成的密钥

如果 AI 写成这样：

ini 复制代码

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

这里至少有两个问题。

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

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

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

typescript 复制代码

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
如果 secret 不允许前后空白，就直接失败
不要把配置错误自动修成另一个值

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

默认值也是 AI 最容易滥用的地方

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

ini 复制代码

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 可以被弱密钥伪造
第三方服务调用失败但应用启动成功
线上流量进入了测试配置
安全问题直到事故发生才暴露

更好的判断标准是：

diff 复制代码

可以默认：
- 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 很喜欢写：

ini 复制代码

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

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

比如：

javascript 复制代码

Number("0") || 5000;

结果是 5000，不是 0。

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

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

typescript 复制代码

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);

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

没配置：使用默认值
配了非法值：启动失败
配了合法值：使用配置值

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

环境变量应该集中读取、集中校验、启动时失败

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

不推荐这样写：

javascript 复制代码

export async function callModel(prompt: string) {
  const apiKey = process.env.OPENAI_API_KEY?.trim() || "";

  if (!apiKey) {
    return null;
  }

  // ...
}

这会带来几个问题：

配置错误运行到某个分支才暴露
每个地方都有一套解析规则
有的地方 trim，有的地方不 trim
有的地方默认，有的地方抛错
测试和生产行为不一致
类型仍然是 string | undefined

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

typescript 复制代码

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 默认生成的代码更长，但它的工程收益很明确：

配置只在启动时读取一次
必填配置缺失时直接失败
默认值只给低风险配置
secret 不会被偷偷修改
数字、枚举、字符串都有明确解析规则
业务代码不用再处理 process.env.xxx
配置错误不会拖到运行中才暴露

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

使用 Zod，比到处手写 if 更稳定

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

javascript 复制代码

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 的问题不是加了 trim，而是不知道哪些地方不能 trim

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

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

但它经常不区分：

配置值和密钥
可选配置和必填配置
开发默认值和生产默认值
空字符串和未配置
非法值和缺省值
可恢复错误和启动失败错误

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

ini 复制代码

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 写配置代码时，不要只说帮我写得健壮一点。这句话很容易让它到处加兜底。

可以直接这样要求：

diff 复制代码

请写一个 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
对生产必填配置拒绝默认值
对 secret 保持原样，并校验异常格式

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

AI 为什么总喜欢写防御性代码？

AI 写防御性代码，本质是在弥补上下文缺失

训练语料也在强化这种写法

防御性代码应该出现在边界，而不是到处出现

读取环境变量时，AI 为什么喜欢加 trim

trim 最大的问题，是它可能改变配置语义

默认值也是 AI 最容易滥用的地方

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

环境变量应该集中读取、集中校验、启动时失败

使用 Zod，比到处手写 if 更稳定

AI 的问题不是加了 trim，而是不知道哪些地方不能 trim

让 AI 少写错误防御代码，可以直接这样约束

总结

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