Collections.singleton用于构建单用户异步通知管道，核心是利用其不可变、线程安全、低开销特性封装用户标识，明确推送上下文，避免null或原始类型歧义，兼容未来批量扩展，配合CompletableFuture安全传递上下文，并作为轻量级“管道头”衔接过滤与分发逻辑。
用 Collections.singleton 构建单用户异步通知管道，核心不是“造轮子”，而是借其不可变、线程安全、开销极低的特性，快速封装一个只服务当前用户的轻量级数据载体——它不替代消息队列，但能干净解耦“谁要收”和“怎么推”。
用 singleton 包装用户标识，明确推送上下文
异步通知任务常需携带目标用户信息（如 userId 或 deviceToken），但又不想暴露完整用户对象或引入额外 DTO。此时用 Collections.singleton(userId) 创建一个只含一个元素的不可变集合，既语义清晰（“就这一个用户”），又天然防误改、免同步。
- 避免传 null 或原始类型参数带来的歧义，比如
notifyAsync(userId)不如notifyAsync(Collections.singleton(userId))明确表达“单目标”意图 - 后续逻辑可统一按
Collection<String>处理，兼容未来可能的批量扩展（比如调试时临时加个测试账号） - 比新建 ArrayList 或 HashSet 更轻：无扩容、无哈希计算、无并发控制开销
与 CompletableFuture 配合，实现无状态任务传递
在异步链中，常需把用户上下文从主线程带入线程池执行体。直接闭包捕获变量易引发内存泄漏或线程安全问题；而用 singleton 集合作为“上下文载具”，配合 CompletableFuture.supplyAsync，自然完成隔离。
- 示例：
CompletableFuture.supplyAsync(() -> sendNotification(userIds), executor)，其中userIds是 singleton 集合，被安全地封闭在 lambda 中 - 若通知逻辑需多次访问用户标识（如查 token、写日志、回调校验），都从该集合取，避免重复传参或依赖外部字段
- 集合本身不可变，即使 executor 中多个阶段共享它，也无需加锁或复制
作为轻量级“管道头”，衔接过滤与分发逻辑
所谓“变量管道”，并非复杂流式结构，而是指从触发点到执行点之间，用户标识能被各环节一致识别、可选增强、不丢失语义。singleton 集合作为起点，天然适合作为这个管道的“头部容器”。
- 下游可基于它做简单判断：比如
if (targets.size() == 1) { directPush(...) }，区分单推与群发路径 - 需要添加元数据时（如推送渠道、优先级），不修改原集合，而是创建新容器：
new NotificationTask(Collections.singleton(userId), Channel.APP, Priority.HIGH) - 日志或监控中打印
targets.toString()，输出形如[u_8823]，简洁可读，不泄露敏感结构
注意边界：它不是状态管理，也不替代配置
singleton 集合只承载瞬时、一次性的推送目标，绝不用于保存用户偏好、设备列表或重试计数等有状态信息。
- 不要把它当缓存用：比如反复复用同一个 singleton 实例去推不同用户——它本意是“这个任务只对某一人”，复用即语义错误
- 不要试图往里加东西：
add、clear等操作会抛UnsupportedOperationException，这是保护机制，不是 bug - 如果业务要求“用户 A 推送失败后自动 fallback 到备用设备”，那 singleton 就该换成包含主备 deviceId 的自定义容器，而非强行塞两个元素
