Java背景开发者提问：JavaScript隐式传参机制与Express回调参数来源

首先纠正一个认知偏差：你举的例子里不存在“隐式参数传递”，所有的传参都是你显式写在调用语句里的，之所以会有“自动传入”的错觉，根源是JS和Java在函数签名设计上的本质差异：

• Java属于强类型编译型语言，所有方法的参数列表、类型、个数都必须在定义阶段显式声明，编译期就会校验所有调用点的传参是否符合签名要求，不匹配直接报错。
• JS属于动态弱类型语言，函数从设计上就不绑定固定的参数签名。函数定义时写的形参列表，只是你为前几个入参起的方便访问的别名，不是强制的入参规则：哪怕你定义一个完全没有形参的函数，调用时传任意个数、任意类型的值，函数内部都可以通过arguments类数组对象或者剩余参数语法拿到所有实参，完全不报错。

对应你的示例代码拆解：

const observer = {
    next: console.log,
    error: console.error,
    test: console.table,
}

observer.next('HI World!')

1. 你给observer.next属性赋值的就是原生console.log函数本身，你根本不需要“显式声明这个函数要接收什么参数”——因为JS的原生方法本身的逻辑已经适配了多入参的接收规则，从一开始就没有要求调用方提前声明参数类型。
2. 你在observer.next后面写的('HI World!')是完全显式的调用表达式，括号里的字符串就是你传给函数的实参，不存在任何“自动传入”的魔法。这个过程和Java里你写System.out.println("HI World!")的逻辑完全一致：你也是把内容写在调用括号里作为实参，只不过Java要求println方法定义时必须声明它接收字符串参数，而JS的console.log不需要。

管道、柯里化的传参逻辑没有“自动隐式传递” #

你提到的pipelining、currying的核心逻辑，和JS的隐式传参没有关系，本质都是显式的函数调用规则：

• 柯里化的本质是把一个多参数的函数拆成多个只接收单参数的函数，每一步的返回值是一个新的函数，每一步传的参数都是你显式写在调用括号里的。比如常见的柯里化函数const add = a => b => a + b，你写add(1)(2)的时候，第一步add(1)返回一个接收b的新函数，第二步的2是你显式传给这个返回函数的实参，没有任何JS底层自动塞值的机制。
• 管道操作（不管是传统的函数组合f(g(x))还是ES的|>管道语法）本质也是语法糖：x |> f等价于f(x)，管道上一步的返回值是明确的实参，被显式传给下一步的函数。这和Java 8 Stream的工作逻辑完全一致：你写stream.map(x=>x+1).filter(x=>x>0)的时候，也没有手动把map的输出传给filter，是Stream API的内部代码帮你显式调用了filter方法、把上一步的结果当实参传进去的——只是Java的强类型会在编译期校验入参类型，看起来“更严谨”，JS没有校验步骤，看起来更随意而已。

首先明确回答你的疑问：你写的路由回调里的req和res，完全不是你手动传入的，是Express框架在内部执行回调时，把自己生成的对象作为实参显式传进去的。整个运行流程和Java Web里的Servlet机制没有本质区别，拆解如下：

1. 你写的这段代码，本质是把一个匿名函数当参数，传给了app.get方法：

   // 你写的逻辑：传入路径 + 回调函数
   app.get('/', function (req, res) {
     res.send('GET request to the homepage');
   });
   

   这个匿名函数从定义开始，直到被框架调用之前，都只是一个存储在内存里的函数值，从来不会被主动执行——就像Java里你写了一个Servlet类，只要容器不调用它的方法，类的逻辑永远不会跑。
2. Express的app.get方法内部，会把你传的路径和回调函数的对应关系存到内部的路由表中，简化的内部实现大概是这样：

   // Express 内部的 get 方法简化逻辑
   app.get = function (path, callback) {
     this.routes.push({
       method: 'GET',
       path: path,
       handler: callback // 把你传的回调存起来
     })
   }
   

3. 当真实的HTTP请求到达服务端、匹配到了对应的路由规则时，Express的网络层会自动完成两个核心动作：
   • 把原始的HTTP请求报文解析成结构化对象，也就是你回调里拿到的req——里面封装了请求头、路径、查询参数、请求体、Cookie等所有请求相关的数据。
   • 把服务端的响应能力封装成结构化对象，也就是你回调里拿到的res——里面封装了send、json、redirect、setHeader等所有响应相关的方法。
   • 最后显式调用之前存在路由表里的回调函数，把req和res作为两个位置参数传进去，简化逻辑如下：

   // Express 收到请求后的简化执行逻辑
   const matchedRoute = 路由表中匹配当前GET请求、路径为/的记录
   const req = 解析原始HTTP请求生成的请求对象
   const res = 封装响应能力的响应对象
   matchedRoute.handler(req, res) // 这一步才是你的回调真正被执行的时刻
   

这个机制和Java里Tomcat处理Servlet请求的逻辑完全一致：你写的Servlet类里的doGet(HttpServletRequest req, HttpServletResponse res)方法，也从来不是你自己new出req和res、然后调用doGet传进去的，是Tomcat容器在收到请求时解析报文、封装好两个对象，然后显式调用你的doGet方法、把这两个对象当参数传进去的。你只需要按照框架约定的形参位置，把变量名写在方法括号里就行，不需要自己手动传值。

JS在1995年首次发布时，从设计到上线只花了10天，核心定位是给浏览器提供轻量的脚本能力，从一开始就没有设计成像Java一样的强类型编译型语言：

• 设计目标是降低浏览器脚本的编写门槛，不需要像Java一样提前声明一堆类型、参数签名，写几行简单的DOM操作就能直接跑。
• 为了适配浏览器的事件驱动场景（比如用户点击按钮、输入框输入、鼠标移动），JS从一开始就把函数设计成一等公民，可以当参数传递给事件监听器，等浏览器触发对应事件时，再把事件对象作为实参传给监听器——这种设计天然不需要开发者手动管理参数的传递时机，只需要把自己写的处理逻辑传进去就行。
• 这种无约束的函数设计后来刚好契合了函数式编程的流行趋势，衍生出了柯里化、管道、函数组合等写法，只是当初设计者没有预料到的额外效果。

内容的提问来源于stack exchange，提问作者MarcL