柯里化与部分应用本质不同：前者强制单参数链式调用（如f(a)(b)(c)），依赖闭包逐层返回函数，强调可组合性；后者预设任意位置参数（如bind或_.partial），保持原函数调用方式，侧重配置简化。
柯里化和部分应用不是同一件事，但常被混用。简单说：柯里化是“强制单步输入”，部分应用是“提前填几个空”——前者重过程、后者重配置。
柯里化：为什么必须写成 f(a)(b)(c)？
柯里化把 add(a, b, c) 变成只能逐个调用的链式函数：add(a)(b)(c)。它不接受跳步（如 add(a)(b, c)），也不允许合并参数（如 add(a, b)(c)），除非你手写的实现特别宽松。
- 核心机制靠闭包保存已传参数，每次返回新函数，直到参数数量等于原函数的
length - 典型用途：需要链式组合的场景，比如
log('error')(msg)或api('v1')('users')，让配置层级清晰 - 常见错误：误以为
curry(fn)(a, b)合法——标准柯里化只收一个参数，多传会忽略或报错（取决于实现） - 性能无实质影响，但过度嵌套（如无限级柯里化）会增加调用栈深度，实际项目中极少需要
部分应用：怎么用 bind 或 Lodash.partial 预设任意位置参数？
部分应用不改变函数“一次接收多少参数”的行为，只是提前塞值。比如 multiply(2, 3, 4)，用 multiply.bind(null, 2) 得到的新函数，后续直接传 (3, 4) 就行。
- 支持任意位置预设：Lodash 的
_.partial(multiply, _, 3, _)表示“第二位固定为 3”，首尾留空 - 真实场景多见于 API 封装：
const apiGet = _.partial(axios.get, { timeout: 5000 })，之后apiGet('/users')自动带超时 - 比柯里化更贴近日常习惯，尤其当参数顺序不友好（如回调在前、数据在后）时，占位符
_能翻转逻辑 - 注意
Function.prototype.bind的第一个参数是this上下文，若不关心上下文，务必传null，否则可能意外绑定错误对象
什么时候该选哪个？看函数是否需要“可组合性”
如果你要拼管道（pipeline）、做高阶函数组合（比如 ['1','2'].map(curry(parseInt)(10))），柯里化更自然；如果只是简化重复调用（如固定主题色、默认请求头），部分应用更直接、语义更清。
Android的资源与国际化设置 中文WORD版
下载
本文档主要讲述的是Android的资源与国际化设置；资源是外部文件（不含代码的文件），它被代码使用并在编译时编入应用程序。Android支持不同类型的资源文件，包括XML，PNG以及JPEG文件XML文件根据描述的不同有不同格式。这份文档描述可以支持什么样的文件，语法，以及各种格式。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
立即学习“Java免费学习笔记（深入）”；
- React 中事件处理器常用柯里化避免内联箭头函数：
onClick={curry(handleClick)(item.id)}，防止每次渲染重建函数 - 但若需预设中间参数（如日志格式器中的时间戳 + 级别），用部分应用配合占位符更灵活：
logWithTime = _.partial(logger, _, 'INFO', new Date()) - 两者可共存：先柯里化再部分应用，比如
curriedAdd(5)既是柯里化中间态，也相当于对首参做了部分应用
function add(a, b, c) {
return a + b + c;
}
// 柯里化实现（简易版）
function curry(fn) {
return function curried(...args) {
if (args.length >= fn.length) return fn(...args);
return (...nextArgs) => curried(...args, ...nextArgs);
};
}
// 部分应用（用 bind）
const add5 = add.bind(null, 5); // 相当于 (b, c) => add(5, b, c)
// 或用 Lodash
const add5and10 = _.partial(add, 5, 10); // (c) => add(5, 10, c)
最容易被忽略的一点：柯里化强调“参数齐了才执行”，而部分应用生成的新函数，只要剩余参数给够就立刻执行——这个延迟/即时的语义差异，在调试异步流程或副作用函数时会暴露得很明显。
