为何在JavaScript中要将对象的所有值转换为字符串？

作为长期在Serverless和JavaScript Lambda领域摸爬的开发者，我完全理解从静态类型语言转过来的你看到这类代码时的诧异——毕竟静态类型体系里的类型安全、输入校验都是默认要做的基础工作，而JS生态里的一些通用做法确实会让习惯强类型的人觉得“太松散”。

先拆解你提到的这个让你诧异的常见做法：大多数JS Lambda函数在接收JSON payload时，会直接执行JSON.parse(event.body)，既不提前校验event.body是否为有效字符串，也不捕获解析可能抛出的异常，甚至很少对解析后的对象做结构校验。

为什么会形成这种习惯？主要有几个原因：

• 早期Lambda的使用场景多为内部服务调用，开发者默认传入的payload是合法合规的，觉得额外校验是冗余工作
• JavaScript的动态特性让开发者形成了“先解析再说，出问题再处理”的思维，觉得即时处理的成本更低
• 不少团队没有引入Schema校验工具的习惯，觉得对于简单场景来说小题大做

但这种做法其实隐藏着不少风险：

• 如果event.body是null或者非JSON格式的字符串，JSON.parse会直接抛出异常，导致Lambda函数返回500错误，而非更合理的400请求错误
• 解析后的对象结构不符合预期时，后续代码会出现各种隐式错误，排查起来非常耗时
• 对于公开触发的Lambda（比如API Gateway前端接入的场景），这种做法完全没有防御恶意输入的能力

给你几个适配JS生态的改进建议，兼顾开发效率和代码健壮性：

• 始终将JSON.parse包裹在try/catch块里，捕获解析异常并返回友好的错误响应：

  let payload;
  try {
    // 先判断event.body是否存在，避免null/undefined传入parse
    if (!event.body) {
      throw new Error("Missing request body");
    }
    payload = JSON.parse(event.body);
  } catch (err) {
    return {
      statusCode: 400,
      body: JSON.stringify({ error: `Invalid request: ${err.message}` })
    };
  }
  

• 引入Schema校验工具（比如Zod、Joi），确保解析后的对象符合预期结构：

  import { z } from "zod";
  
  // 定义payload的结构规则
  const RequestPayloadSchema = z.object({
    userId: z.string().uuid(),
    amount: z.number().positive().min(1)
  });
  
  // 安全校验，避免抛出异常
  const validationResult = RequestPayloadSchema.safeParse(payload);
  if (!validationResult.success) {
    return {
      statusCode: 400,
      body: JSON.stringify({ 
        error: "Invalid payload structure",
        details: validationResult.error.errors 
      })
    };
  }
  
  // 使用校验后的安全数据
  const validPayload = validationResult.data;
  

• 对于API Gateway触发的Lambda，可以在API层配置基础的JSON校验规则，提前拦截无效请求，减轻Lambda的处理负担

从静态类型语言转过来，你可能会觉得这些额外步骤有点繁琐，但这确实是JS生态里平衡开发效率和代码可靠性的常见思路——毕竟动态语言没有编译时的类型检查，只能靠运行时的校验来补全类型安全的缺口。

内容的提问来源于stack exchange，提问作者salva.juan