imba 不直接解析或执行 `<script>` 标签内的裸 javascript，需将 js 逻辑转为字符串并借助 `eval` 或生命周期钩子执行；推荐使用 `onmount` 钩子替代内联脚本，兼顾安全性、可维护性与响应式一致性。</script>
在 Imba 中，不能像传统 HTML 那样直接在组件内嵌入可执行的 <script> 标签。你提供的示例：
<script type="application/javascript">
document.getElementById('print').innerHTML = "Hello"会被 Imba 编译器视为静态 DOM 节点（即一个 <script> 元素），但其内容不会自动执行——这与浏览器解析纯 HTML 文件的行为有本质区别。Imba 的模板系统专注于声明式 UI 构建，所有逻辑应通过 Imba 语法或受控的 JavaScript 集成方式表达。
✅ 正确做法：使用 onmount 生命周期钩子（推荐）
onmount 是 Imba 提供的组件挂载后立即执行的钩子，语义清晰、作用域明确、与组件生命周期强绑定，且天然支持响应式更新：
tag script-app
<self>
<h4> "Running js/ts inside Imba elements"
<div id='print'>
def onmount
# 安全访问当前组件内的 DOM 节点
@ref('print').innerHTML = "Hello from Imba's onmount!"
imba.mount <script-app>? 提示：使用 @ref 可避免 getElementById 的全局查找，提升性能与可维护性。只需在元素上添加 ref='print'：<div ref='print'>
⚠️ 替代方案：字符串化 + eval（不推荐，仅作了解）
原始答案中提到的“用字符串包裹 JS 代码”方式（如下）技术上可行但存在严重风险：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
<script type="application/javascript">
'document.getElementById("print").innerHTML = "Hello"'该写法依赖外部机制（如手动 eval）执行字符串，不仅破坏 Imba 的类型安全与编译时优化，更引入 XSS 漏洞、调试困难、无法热重载等问题。生产环境严禁使用。
? 补充说明：为什么 <script> 在 Imba 中不执行？
- Imba 模板编译为高效的原生 DOM 操作代码，而非运行时 HTML 解析；
- <script> 标签被当作普通元素渲染（类似 <div>），其 textContent 不会被浏览器识别为可执行脚本；
- 浏览器只在初始 HTML 解析阶段执行内联 <script>，而 Imba 渲染发生在 DOMContentLoaded 之后。
✅ 最佳实践总结
| 场景 | 推荐方式 | 原因 |
|---|---|---|
| 初始化 DOM 操作（如第三方库集成） | onmount 钩子 | 生命周期明确、作用域可控、可访问 @refs |
| 动态响应数据变化 | 使用 Imba 响应式绑定（{} 插值或 def render） | 声明式、自动更新、无副作用 |
| 需调用原生 JS 库（如 Chart.js） | onmount + @ref 获取容器节点 | 避免 ID 冲突，便于组件复用 |
| 跨组件共享逻辑 | 抽离为 Imba 函数或自定义 Hook（如 useChart） | 提升可测试性与复用性 |
始终优先使用 Imba 的响应式能力替代手动 DOM 操作。例如，上述“Hello”示例更地道的写法是：
tag script-app
<self>
<h4> "Running js/ts inside Imba elements"
<div> "Hello from Imba"
imba.mount <script-app>——简洁、安全、可预测，这才是 Imba “以数据驱动视图”的设计哲学所在。
