严格模式通过禁止隐式全局变量创建，在赋值瞬间抛出 ReferenceError，强制开发者使用 let/const/var 显式声明变量，从而提升代码可维护性与运行时安全性。
严格模式通过禁止隐式全局变量创建，在赋值瞬间抛出 referenceerror，强制开发者使用 let/const/var 显式声明变量，从而提升代码可维护性与运行时安全性。
你遇到的错误 Cannot find name 'items'. Did you mean 'item'? 'items' is not defined，表面看是变量未定义，但其根本原因并非 JavaScript 作用域失效，而是上下文环境错位——这段代码并非纯 JavaScript 脚本，而是嵌入在 Svelte 组件模板中 的混合结构。
Svelte 是一个编译型前端框架，它对 <script></script> 标签的位置和语义有严格约定：
✅ 仅当 <script></script> 位于组件顶层（即文件最上方、无任何 HTML 或文本前置）时，其中声明的变量（如 let items = [...]）才会被识别为组件级响应式状态，并可在后续 {#each} 等模板语法中直接引用。
❌ 若 <script></script> 写在 内、或被 HTML 标签包裹（如你的示例中 <script></script> 出现在 <div class="header"> 之后），Svelte 编译器会将其视为普通浏览器脚本（<code><script type="text/javascript"></script>），此时变量仅存在于该 <script></script> 执行的作用域内，完全无法被下方的 Svelte 模板语法访问 —— 这正是 items is not defined 的真实来源。
? 类比理解：这就像在教室里老师（Svelte 编译器）只认讲台上的教案（顶层
<script></script>），你在课桌底下偷偷写的小纸条（body 内<script></script>）再工整，老师也看不见、不生效。
因此，修复方案不是“加 use strict”或改用 var，而是重构组件结构，遵循 Svelte 的标准范式：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
<!-- ✅ 正确的 Svelte 组件结构 -->
<script>
// ✅ 顶层 script：声明可被模板访问的状态
export let items = [
{ name: "test" },
{ name: "potato" },
{ name: "io" }
];
</script><!-- ✅ 模板区：可安全使用 items --><div class="cnt1">
{#each items as item}
<div class="item">
<h1>{item.name}</h1>
</div>
{/each}
</div>
<!-- ✅ 样式区：自动作用域隔离 -->
<style>
.cnt1 {
display: flex;
background-color: #127D0B;
padding: 8px 50px;
}
.item h1 {
margin: 0;
}
</style>
⚠️ 关键注意事项：
-
export let items是必需的：Svelte 要求暴露给模板的变量必须显式导出（export let），这是组件 props 机制的一部分；仅let items = [...]不加export仍不可见。 -
禁止在组件内构造完整 HTML 文档：
、标签不应出现在.svelte文件中（除特殊场景如svelte:head）。样式应移至<style></style>块，逻辑置于顶层<script></script>。 -
严格模式在此自动生效：Svelte 编译输出的 JS 默认启用严格模式，无需手动添加
"use strict"；你真正需要的是正确的框架语义，而非底层 JS 模式切换。
总结来说：ReferenceError: items is not defined 在 Svelte 中，99% 是结构违规信号，而非 JavaScript 语法错误。牢记「顶层 <script></script> + export let + 无冗余 HTML」三原则，即可彻底规避此类问题。这也印证了现代前端开发的核心逻辑：框架规则优先于语言规则，语义正确性远胜于语法合法性。
