Angular为何禁止定义以'on'开头的@Output事件？安全风险何在？

你遇到的这个限制，其实是Angular框架为了避免混淆和安全风险特意设计的，我来给你详细拆解一下：

核心原因一：避免与原生DOM事件机制冲突 #

Angular的模板绑定语法里，(eventName) 本质上是对应原生DOM的onEventName事件的语法糖。比如你写(click)，Angular会帮你绑定到原生的onclick事件。如果允许组件定义以on开头的@Output（比如onUploaded），就会和这个原生事件的映射机制产生冲突：

• Angular会无法区分你到底是想绑定组件的自定义onUploaded输出，还是想绑定一个不存在的原生onuploaded事件
• 这种混淆会导致模板解析错误，甚至出现不符合预期的事件绑定行为

所以框架强制要求自定义输出去掉前缀on，用(uploaded)来绑定组件的@Output() uploaded = new EventEmitter()，这样就能和原生事件的绑定逻辑彻底区分开。

核心原因二：防止恶意组件的事件劫持风险 #

这就是错误提示里提到的“安全考虑”的核心：

• 如果允许组件定义onClick、onLoad这类和原生事件同名（或前缀一致）的输出，恶意组件就可以伪装成原生事件，劫持开发者的事件绑定逻辑。比如开发者本来想绑定原生的点击事件，结果不小心绑定到了组件自定义的onClick输出，而这个输出可能被恶意组件用来执行未经授权的操作。
• 另外，这种命名混淆也会让开发者难以排查问题，比如明明写了(onClick)，却发现触发的不是原生点击行为，而是组件的自定义逻辑，增加了调试成本，也可能埋下安全隐患。

Angular通过禁止on开头的自定义输出，强制划清了组件自定义事件和原生DOM事件的边界，既保证了框架解析的一致性，也从根源上避免了这类混淆带来的安全问题。

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