应直接使用 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>，传入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 关联
