柯里化不自动保留 this，需显式绑定或传入上下文实体。应避免箭头函数干扰，用 apply 传递 this，或传入明确对象（如 apiClient）代替依赖 this；可结合 bind 先固定 this 和参数，再柯里化；异步链中须显式注入动态上下文，避免全局状态污染。
柯里化本身不自动保留 this，函数执行时上下文丢失是常见问题。解决的关键不是“让闭包自动记住 this”，而是主动捕获并显式传递真正需要的上下文实体。
用 apply 显式绑定 this，避免箭头函数干扰
柯里化中间函数必须能正确把 this 传给原函数。不能用箭头函数写主干逻辑，因为它没有自己的 this，也无法被 call 或 apply 修改。
- 每次执行原函数时，统一用
fn.apply(this, args)，确保调用时的this被如实传递 - 若想固化某个对象为
this，可在柯里化入口接收一个context参数，并在最终执行时固定使用它：fn.apply(context, args) - 不要依赖调用位置推断
this，比如事件回调或setTimeout中直接传方法，这种场景下this几乎必然丢失
把上下文实体作为自由变量捕获，而非依赖 this
比起绑定 this，更稳定的做法是把真正需要的对象（如 API 实例、配置、用户 token）作为参数传入柯里化过程，并由闭包长期持有。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 例如：
const fetchUser = curry(fetchWithAuth)(apiClient)('user')，其中apiClient是明确传入的实例，不是靠this推导 - 这样多个请求可并行运行，各自闭包持有独立的
apiClient副本，互不干扰 - 后续更新
apiClient.token，已生成的柯里化函数下次调用就能用上新值
与 bind 协作：先 bind 固定 this 和基础参数，再柯里化剩余部分
bind 天然支持 this 绑定和参数预设，和柯里化搭配使用更清晰可靠。
- 先用
bind锁定this和前几个稳定参数：const apiCall = originalFn.bind(instance, baseUrl, timeout) - 再对
apiCall进行柯里化，处理动态参数（如userId、query） - 这样既利用了
bind对this的强保障，又保留了柯里化对参数分步的灵活性
异步链中不依赖隐式上下文，每层显式携带
在 fetch → .then → .catch 这类链式调用中，上下文容易断裂。柯里化函数不能假设“环境还记得我”。
- 错误处理器如
reportError('error')('auth')应该只负责格式化和上报，不依赖组件实例或请求上下文 - 若需访问当前请求 ID、用户 locale 等，应在发起请求时就注入，例如：
safeFetch(locale)(userId)，把动态上下文作为柯里化参数传下去 - 避免在柯里化函数内部读取全局状态或模块级变量，那会带来多请求间污染风险
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
