2. IE大战时期：微软表示"俺也要搞事情"，于是诞生了 `attachEvent('onclick', handler)`

（注意这个傲娇的'on'前缀）

3. 现代标准：最终W3C一锤定音——所有事件处理属性统一带"on"前缀，就像给变量名加`$`一样成了行业黑话。

冷知识：如果不用"on"，解析器会以为你要调用方法。比如`document.click()`是真的有个click方法（用来模拟点击），而`document.onclick`才是事件处理器！

三、专业选手的骚操作

来看个高端玩法（推眼镜.jpg）：

// 正经人写法

server.on('connection', (socket) => {

socket.on('data', (chunk) => {

console.log(`收到${chunk.length}字节数据`);

// 这里可以玩出花：

chunk.toString().split('\n').forEach(line => {

if(line.startsWith('GET /腹肌照 HTTP')) {

socket.write('HTTP/1.1 404 Not Found\r\n\r\n');

}

});

});

});

为什么Node.js也爱用'on'？

1. 明确语义：看到'on'就知道在监听事件，就像看到'￥'知道要花钱一样直观

2. 避免冲突：方法名和事件名可以和平共处（比如`server.close()`和`server.on('close')`）

3. IDE友好：输入'on'后智能提示直接列出所有事件，简直像开了透视挂

四、不加'on'的翻车现场

某不愿透露姓名的程序员小李曾写下：

// 错误示范！请勿模仿！

httpServer.request = (req, res) => {

res.end('Hello World');

};

结果他的服务器表现得像极了甲方需求：

- 第一次请求：正常响应

- 第二次请求："Hello WorldHello World"

- 第三次请求："Hello WorldHello WorldHello World"

因为这不是事件监听而是在不断重写方法啊！（拍桌大笑.gif）

五、行业黑话大全

最后奉上老K私藏的《服务器事件黑话手册》：

| 带'on'的正确姿势 | 不带'on'的危险操作 | 后果 |

||-||

| `socket.on('data')` | `socket.data()` | 你以为在收数据实际在发数据 |

| `stream.on('end')` | `stream.end()` | 直接结束流哭给你看 |

| `emitter.on('error')`| `emitter.error()` | 手动制造错误堪称程序员迷惑行为大赏 |

六、终极哲学问题

有萌新可能要问："老K老K，为啥不统一规定所有方法都带'on'呢？"

这就好比问："为啥汉堡不全是面包片？" ——因为我们需要区分什么是"原料"（方法），什么是"吃法"（事件）啊！

下次看到'on'前缀，请给它一个关爱的眼神——它不是多余的装饰品，而是防止你把油门当刹车的安全护栏！

（突然正经）最后下知识点：

1. 'on'前缀是W3C规范要求的事件处理属性标志

2. Node.js等后端框架延续了这个约定保持一致性

3. 能明确区分方法和事件监听器

4. IDE和代码分析工具依赖这个约定提供智能提示

我是你们的欢乐码农老K，下期咱们聊《HTTP状态码之404的108种花式用法》，记得一键三连！（突然消失.gif）

TAG:服务器端事件为什么要加on,服务器事件id41,服务器事件id,为什么使用服务器端脚本,为什么要用服务器上运行程序,服务器为什么要重启