柯里化本身不自动带来惰性求值，但二者协同需在每层柯里化函数中返回惰性包装对象（如Lazy<T>或lazy(fn)），配合memoization缓存首次求值结果，从而实现参数逐步传入、最终统一计算的渐进式执行。
柯里化本身不自动带来惰性求值，但二者可以自然协同：柯里化把多参数函数拆成单参数链，为“按需触发计算”提供了结构基础；惰性求值则负责延迟执行并缓存结果。真正起作用的是——在柯里化链条的每个环节，用惰性包装替代立即求值。
柯里化提供分步入口，惰性求值控制执行时机
柯里化生成的是一串嵌套函数（如 f(a)(b)(c)），但默认每次调用都会实时运算。若想实现“传入 a 后不计算，等到传完 c 才真正算”，就需要在每层返回值中包裹一个惰性容器（如 Java 的 Lazy<T>、JS 的自定义 lazy(fn) 或 Python 的 functools.lru_cache + 闭包）。这样，中间状态（比如已传入的 a 和 b）不会立刻参与运算，而是被暂存，直到最终调用时才统一展开。
- 不是“柯里化后自动惰性”，而是“柯里化 + 惰性包装”才能达成渐进式计算
- 关键在于：每层柯里化函数返回的不是原始计算结果，而是一个可延迟求值的代理对象
- 例如 JS 中：
curryAdd = a => b => lazy(() => a + b)，b层不执行加法，只构造惰性对象
中间状态缓存依赖惰性容器的 memoization 机制
单纯延迟还不够——若多次调用同一层（如反复传入相同 a），应复用之前的结果。这就要求惰性包装具备记忆能力（memoization）。Java 的 Lazy<T> 类通过 value 字段缓存首次计算结果；JS 可用闭包变量或 WeakMap 存储已求值结果；Python 则常用 @lru_cache 装饰器或自定义 descriptor。
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 缓存发生在“惰性对象的
get()/force()方法首次调用时” - 柯里化链条中任意一环的惰性对象，只要参数不变，后续调用直接返回缓存值
- 例如：对
curryMultiply(5)返回的函数多次调用(2)，若内部是惰性+缓存，则第二次起跳过乘法运算
组合使用时需注意求值边界与副作用
惰性求值推迟了副作用（如日志、IO、状态变更）的发生时间，而柯里化可能让这些副作用出现在意想不到的位置。比如：curryLogThenAdd = msg => x => lazy(() => { console.log(msg); return x + 1; })，console.log 不会在 curryLogThenAdd('start') 时执行，而要等到 result.get() 被显式调用。
- 纯函数场景下安全；含副作用时，必须明确“谁触发求值”以及“何时触发”
- 避免在惰性对象构造时做不可逆操作（如文件打开、网络请求），应推迟到
get()中 - 柯里化后的函数若返回多个惰性对象，需确保它们的求值顺序符合业务逻辑（如依赖关系）
实际应用中的典型模式
常见于配置驱动的计算流程，例如构建一个可逐步注入参数的查询构造器：
- 第一步：
buildQuery = db => table => fields => lazy(() => `SELECT ${fields} FROM ${table} ON ${db}`) - 第二步：传入
buildQuery('pg')得到新函数，不连接数据库；传入table后仍不查表；直到最后调用.get()才真正拼 SQL 并执行 - 中间每一步都可复用（同 db + 同 table 的不同 fields 查询共享前两步结果），且整个过程支持无限扩展参数维度
