这是一个坏主意，因为...

1. 最佳实践建议明确划分内容、风格和脚本。使用内联 JavaScript（或 CSS）混淆您的 HTML 与此不一致。

2. 例如，您只能使用on*-style events绑定每种类型的一个事件，因此您不能有两个onclick事件处理程序。

3. 如果内联指定事件，则 JS 将指定为字符串（属性值始终为字符串）并在事件触发时进行评估。评价是邪恶的。

4. 您面临着必须引用命名函数的问题。这并不总是理想的（事件处理程序通常采用匿名函数）并且对需要全局访问的函数有影响

5. 您的内容安全策略 (CSP) 必须（不明智地）扩展以允许评估的内联 JavaScript。

简而言之，通过专用addEventListenerAPI 或通过 jQuery 或其他方式集中处理事件。

[2021 编辑]

如今，react式框架在某种程度上扭转了这一趋势。响应式框架中的事件通常被指定为属性，例如在 Vue 中：

<p v-on:click=foo>Hello</p>

... wherefoo是当前组件的数据对象的方法。

除了接受的答案中表达的语义和其他意见之外，所有内联脚本都被认为是一个漏洞和高安全风险。任何希望在现代浏览器上运行的网站都应该通过元属性或标头设置“内容安全策略”（CSP）属性。

这样做与所有内联脚本和样式不兼容，除非明确允许这些作为排除项。虽然 CSP 的目标主要是防止持久性跨站点脚本 (xss) 威胁，其中内联脚本和样式是 xss 的向量，但它目前不是浏览器中的默认行为，但将来可能会发生变化。

以@Mitya 答案为基础。

在大多数现代 JS 库中React、Vue等。内联事件处理程序被认为是惯用的，但@Mitya 提到的大部分限制都消失了。作为案例研究，我们将查看Vuejs并将其与上面列出的点进行比较：

1. 您可以拥有多个事件处理程序，请看这里
2. 事件值（处理程序）例如onclick不是纯字符串而是 js 表达式看这里
3. 全局范围问题根本不存在（因为您的代码将被翻译成小型化，由webpack或其他工具重新打包）。

在我看来，内联事件处理程序主要提高可读性，但意见可能会有所不同。