应直接使用 context.tenant_id 实现租户隔离，一次获取、按需隔离，避免跨租户污染；优先于 event 解析，禁止初始化阶段访问，显式判空而非 try-catch；用 lambda 封装租户逻辑，结合环境变量前缀配置和结构化日志自动携带 tenant_id。

直接在 Lambda 处理函数中读取 context.tenant_id，配合轻量级闭包逻辑做租户上下文切换，无需手动维护线程局部变量（ThreadLocal）或全局状态映射表。关键在于“一次获取、按需隔离”，避免跨租户污染。

租户标识从上下文直达业务逻辑

租户 ID 在调用阶段就已注入 context 对象，不需要额外解析 event 或 headers。所有租户感知操作都应以 tenant_id 为第一输入参数，而非通过条件分支反复判断。

• 始终优先使用 context.tenant_id，它比从 event 中提取更可靠、更安全
• 不要在初始化阶段尝试访问 tenant_id —— 此时该属性尚未设置，会抛出 AttributeError 或 NullPointerException
• 若需默认租户兜底，建议显式检查是否为空字符串或 null，而不是依赖 try-catch

用 Lambda 表达式封装租户隔离行为

把租户相关配置加载、数据源路由、权限校验等重复逻辑，抽象成可复用的函数式接口，再用 Lambda 实例化。这样既保持无状态性，又避免硬编码 if-else 分支。

• 例如定义 Function<string datasource></string>，传入 tenant_id 返回对应数据库连接池
• 对 DynamoDB 查询，用 (tenantId, userId) -> table.getItem(key: {tenant_id: tenantId, user_id: userId}) 直接构造复合主键
• 避免在 Lambda 内部捕获大量外部对象（如整个 config bean），只捕获真正需要的字段，减少闭包开销

结合环境变量做租户级配置分发

将不同租户共用但值不同的配置项（如 API 超时、重试次数、功能开关）提前写入环境变量，键名带租户前缀，再用 Lambda 动态拼接读取。

• 例如设置环境变量：BLUE_API_TIMEOUT=5000、GREEN_API_TIMEOUT=8000
• 代码中： int timeout = Integer.parseInt(System.getenv(tenantId.toUpperCase() + "_API_TIMEOUT"))
• 注意：环境变量总大小不能超 4KB，高频变动项建议改用 Secrets Manager 或 Parameter Store

日志与监控自动携带租户上下文

启用 JSON 格式日志后，Lambda 自动将 tenant_id 注入每条日志结构体。你只需在业务日志中统一添加 "tenant_id" 字段，就能在 CloudWatch Logs Insights 中快速筛选、聚合。

• 推荐日志格式：{"event":"user_login","tenant_id":"blue","timestamp":...}
• 在指标维度中增加 TenantId，便于按租户查看错误率、延迟 P95 等
• 调试时，直接用 filter @message like /tenant_id="blue"/ 定位问题，不用翻查 trace ID 关联