我先不写“博客模板”那种板起脸的教学腔，直接说点实际的。JavaScript 这个词，但凡接触过网页开发的人都不可能绕开——它是目前浏览器里唯一不需要额外安装环境就能原生运行的语言，也是新手打开浏览器控制台敲下的第一行代码大多是console.log('Hello World')的原因。但很多新手第一次卡住的地方，往往不是语法本身，而是一个特别基础的问题：这段 JS 代码，到底应该写在哪个地方？
我见过不少刚入门前端的朋友，照着网上的代码拿过来，结果要么页面白屏，要么控制台报错，要么按钮怎么点都没反应。研究半天才发现，问题不是逻辑错了，而是代码放的位置不对。今天这篇文章就把 JavaScript 的 3 种书写位置拆开聊透，顺便把和它紧密相关的加载顺序、作用域问题、常见报错一并说清楚，应该能帮你在起步阶段少走很多弯路。
1. 先看清楚：的问题是什么
1.1 三种书写位置的一次性全景对比
JavaScript 写进网页里，总结起来就三条路：外部文件、内部<script>标签、行内事件属性。很多教程会直接告诉你“外部文件最好，内部标签凑合，行内不要用”，但不说为什么，新手听完只觉得是背口诀。我这里先给一张对比表，把底层逻辑铺开：
| 书写位置 | 典型写法 | 加载时机 | 适用场景 | 坑点 |
|---|---|---|---|---|
| 外部文件 | <script src="app.js"></script> | 触发 HTTP 请求加载文件，之后执行 | 多页面复用、工程化项目、代码量较大 | 路径容易写错，存在加载顺序问题 |
| 内部标签 | <script> ... </script> | 解析到标签时立即执行 | 单页 Demo、临时调试、页面私有脚本 | 复用性差，变量容易污染全局 |
| 行内属性 | <button onclick="clickHandler()"> | 用户触发事件时才执行 | 几乎不推荐 | 转义麻烦，HTML 与逻辑深度耦合 |
你会发现，这三种方式背后其实是同一个问题：JS 引擎拿到代码的时机不同。所以问题的关键不在于“能不能用”，而在于“什么时候执行、在什么作用域里执行”。理解了这一点，以后再看到任何一段前端代码，你都能条件反射式地判断它应该放在哪。
1.2 为什么“写在哪”比“怎么写”更先决定成败
举一个很经典的例子。你在 HTML 的<head>里写了一个内部脚本，想给页面底部的一个按钮绑定点击事件：
<head> <script> const btn = document.getElementById('submitBtn'); btn.addEventListener('click', function() { alert('你点了我'); }); </script> </head> <body> <button id="submitBtn">提交</button> </body>看似逻辑没有问题，但实际运行起来控制台十有八九报Cannot read properties of null，原因就是脚本执行的那一刻，<body>里的按钮还没被浏览器解析出来，getElementById找不到这个元素。这不是代码逻辑的问题，是代码位置的问题。
类似的坑在外部文件和行内属性里同样存在。所以我一直跟新手强调：学 JavaScript 的第一课，不是变量也不是函数，而是先理解“脚本与 HTML 文档的相遇时机”。把这个问题搞明白，后面遇到的各种白屏、报错、事件不触发，你会有更强的排查方向感。
2. 外部 JavaScript 文件：工程化项目的绝对首选
2.1 基本写法与路径的那些细节
外部文件的标准写法是：
<script src="./js/app.js"></script>这里src属性的值就是 JS 文件的路径。新手最容易在这上面踩坑的就是路径写错——本地打开页面时可能没问题，一旦部署到服务器上就 404。路径的本质分三种，一定要分清：
- 相对路径：
./js/app.js或../js/app.js，相对于当前 HTML 文件所在目录。./表示当前目录，../表示上一级目录。 - 绝对路径：
/js/app.js，以根目录为起点。注意这里的根目录是指网站的根目录，而不是服务器文件系统的根目录，很多刚接触部署的同学在这里懵过。 - 完整 URL：
https://cdn.example.com/lib/app.js，完整地址，通常用于加载公共 CDN 资源。
我个人的建议是：自己项目里的文件一律用相对路径或根相对路径（以/开头），这样不管项目放在哪个目录都能正确定位。只有加载第三方公共库（比如 Vue、React、jQuery）时，才建议直接用公共 CDN 的完整 URL，省去自己下载维护的麻烦。
2.2 为什么外部脚本是业界默认的主流方案
外部文件最大的优势不是“规范”，而是三个实打实的好处：
- 可维护性高。代码按文件拆分之后，逻辑清晰，多人协作各改各的文件，不会互相踩踏。比如
utils.js放工具函数，list.js放列表渲染逻辑，validate.js放表单校验，各司其职。 - 浏览器缓存效率高。外部 JS 文件可以被浏览器缓存。用户第一次访问加载过一次之后，下次再来，浏览器直接从本地缓存读取，不用重新下载。对页面性能的提升非常明显，尤其是那些体积较大的业务脚本。
- HTML 结构干净。把脚本从 HTML 里抽出去，HTML 只负责描述页面结构，就是所谓“结构、样式、行为分离”的起点。与其等到项目变大再重构，不如从一开始就养成这个习惯。
还有个容易忽略的点：多个页面共享同一个外部 JS 时，只需要在一个文件里改代码，所有页面都会同步生效。如果你用的是内部脚本，同样一段代码复制粘贴在十几个页面里，一旦要改，就是一场灾难。
2.3 加载优化：defer 与 async 到底怎么选
外部脚本的加载会阻塞 HTML 解析，所以大家在实践中摸索出了defer和async两个属性来解决这个问题。这两个属性都是给<script>标签用的，作用看名字就能猜个大概：
defer（延迟执行）：浏览器会一边继续解析 HTML，一边后台下载脚本，等整个 HTML 解析完、DOM 就绪之后再执行脚本。多个带defer的脚本会按书写顺序依次执行。async（异步执行）：浏览器同样一边解析一边下载脚本，但下载完成之后立即执行，执行时会中断 HTML 解析。多个async脚本的执行顺序无法保证，谁先下载完谁先执行。
给新手的建议：如果脚本之间有依赖关系，用defer；如果脚本互相独立，且不依赖 DOM 结构，可以用async。最安全的默认选择就是defer。
一个实际案例，你需要引入一个统计脚本和一个业务脚本，两者互不相关：
<script src="https://cdn.example.com/analytics.js" async></script> <script src="./js/business.js" defer></script>这样页面不会因为加载脚本而卡住，用户体验会好很多。这个知识点虽然位置稍微靠后一点，但绝对值得从一开始就了解。
3. 内部 Script 标签：小场景里的实用方案
3.1 什么时候用内部脚本最合理
内部脚本就是直接把代码写在<script>和</script>之间，不需要额外文件。听上去不够“工程化”，但有些场景它就是最合适的方案：
- 写小型 Demo 或教学示例。比如你只是想测试一段算法逻辑，没必要单独建一个 JS 文件。
- 做临时调试。在页面里临时加一段脚本来观察 DOM 状态，调试完直接删，省得来回改文件路径。
- 页面私有、复用性极低的逻辑。比如某个页面特有的初始化配置，写进外部文件反而显得零散。
- 服务端模板直接生成的动态参数。有时候后端渲染页面时，需要把一些数据直接以 JS 变量的形式嵌进页面里，这是最直接的做法。
注意，内部脚本和外部脚本是可以共存的。你完全可以在头部引入一个外部公共库，然后在页面底部再写一个内部脚本去调用它，这是非常常见的组合方式。
3.2 放哪里才对：head 与 body 的经典之争
内部脚本放在哪个标签里，直接决定脚本执行时 DOM 是否就绪。前面已经演示过放head里会找不到元素，那是不是内部脚本就不能放head了？也不是，关键看你的代码依赖什么。
如果脚本只是定义一些函数，不立即操作 DOM，放head里没问题，因为函数只是“定义”了，还没被调用。但是，如果你在顶层就直接执行了document.querySelector，那就必须保证标签出现在 DOM 树之后。新手最容易记住的通用规则是：把内部脚本放在</body>结束标签之前，这样它能访问到页面上所有元素，而且不会阻塞上面内容的渲染。
<body> <div class="app"></div> <script> const app = document.querySelector('.app'); app.innerHTML = '<p>内容已由 JS 渲染</p>'; </script> </body>上面的代码之所以安全，是因为脚本执行时.app已经存在了。
3.3 内部脚本躲不开的两个隐患
内部脚本虽方便，但隐患也很明显。第一个是变量污染全局。你在脚本里声明一个const count = 1，它就变成了全局作用域的一部分，页面上其他脚本也能看到它，一旦两边定义了同名的count，就会冲突。多人协作时这个问题尤其明显，你根本不知道哪个同事在别的脚本里用了什么变量名。
第二个是依赖顺序脆弱。内部脚本如果依赖外部脚本里的变量，那你必须保证外部脚本先加载完。可一旦换成async加载，顺序就不可控，页面可能时好时坏。这就是为什么大项目基本都放弃手动管理<script>顺序，投入到模块化打包工具的怀抱——这是后话了，但你应该有这个意识。
4. 行内事件属性：最该避开的“新手陷阱”
4.1 行内写法的两种常见形式
行内方式，指的是把 JavaScript 直接写在 HTML 标签的属性里。最常见的就是事件属性，比如：
<button onclick="alert('我被点击了')">点我</button>还有一类是利用javascript:协议的 URL，比如早期的“死链接”写法：
<a href="javascript:void(0);">点击后不跳转</a>这两种形式的本质是一样的：把一小段代码“塞”进 HTML 属性中，浏览器在特定时机去执行这些代码。对于极小的交互来说，这种写法确实够快，复制粘贴就能用。但我不建议你在任何真实项目里这么干。
4.2 为什么教程都劝你别用它
劝退行内写法，不是因为它不能运行，而是它的问题太多。我从最直观的逐条捋一下：
- 结构行为严重耦合。HTML 管结构，JS 管行为，行内写法把两者焊死。下次你想改行为逻辑，得去翻 HTML 文件；想改 HTML 结构，又怕碰坏 JS 属性，维护成本直线上升。
- 转义引号麻烦得令人抓狂。HTML 属性值要么用双引号要么用单引号，JS 代码里也有字符串引号，混在一起简直是引号地狱。比如：
<button onclick="alert('他说：\'你好\'')">点我</button>这还算短的，代码一长就是灾难。
- 作用域不如普通脚本直观。行内代码的执行环境比较特殊，this 的指向、变量查找都和常规脚本不同，新手一旦理解偏差，调试起来非常痛苦。
- 安全隐患。行内脚本与 CSP（内容安全策略）天然冲突。现代网站为了防 XSS，往往会在 HTTP 头里设置 CSP 规则禁止行内脚本执行，到时候你的代码直接被拦截，页面功能莫名其妙失效。
总之，行内写法只适合你在控制台临时验证想法，或者做单文件 Demo 时图个方便。一旦进入正式开发，请把它当成禁区。
5. 从“写在哪”延伸到“怎么执行”：加载机制与报错实录
5.1 脚本执行时机：理解浏览器到底干了什么
无论你选择上面哪种方式，最终都要经过浏览器这一关。浏览器解析 HTML 文档时，是从上到下一行一行读的。遇到<script>标签（没有 defer 或 async 时），浏览器会停下来，先把脚本下载或解析执行完，再继续往下解析 HTML。
这就是为什么脚本放在head里会让页面“变慢”的原因——浏览器卡在那里执行脚本，后面的 HTML 内容只能排队等着。把脚本放到body末尾，目的就是让页面主体先渲染出来，用户能立刻看到内容，脚本在后台再去执行。
这个概念理解透了，你就知道之前遇到的很多诡异问题是怎么回事了。比如页面加载完成之前按钮没反应，是因为对应的 JS 还没执行；某些时刻数据渲染不出来，是因为脚本执行了但 DOM 还没生成完。
5.2 运行时错误怎么看：控制台是新手最好的老师
脚本位置放错了，或者逻辑有问题，JavaScript 引擎往往会在运行时抛出错误。新手一定要养成看控制台的习惯——在浏览器里按 F12，切换到 Console（控制台）面板，所有报错信息都在那里。
常见的几类报错：
Uncaught SyntaxError：语法错误。多半是括号不匹配、少了分号或引号没闭合。这种错误会导致整个脚本无法执行。Uncaught ReferenceError: xxx is not defined：变量未定义。你用了某个变量，但之前没声明或不在当前作用域。Uncaught TypeError: Cannot read properties of null：前面提到的 DOM 未找到，或调用了不存在的方法。Failed to load resource: 404：外部脚本路径错误，浏览器根本找不到文件。
给你一个排查顺序建议：先看 HTTP 状态（网络面板里请求是否 404），再看控制台有没有红色报错，最后看代码执行顺序。这个问题我见过太多同学卡住，但其实九成以上都是这三个原因之一。
5.3 顺手解决两个热词需求：类型判断、保留两位小数
既然热搜词里反复出现“javascript判断数据类型”和“javascript保留两位小数”，我在这里顺便把新手阶段百分之百会碰到的两个函数私货放出来，都是实战直接能用的。
判断数据类型，新手最常犯的错是直接用typeof。typeof []返回object，typeof null也返回object，完全不是你想要的。更稳的办法是使用Object.prototype.toString配合call：
function getType(val) { return Object.prototype.toString.call(val).slice(8, -1); } console.log(getType([])); // "Array" console.log(getType(null)); // "Null"保留两位小数，直接调toFixed(2)有个坑：它返回的是字符串，不是数字。如果你后续还要做算术运算，记得用Number()包一层，或者干脆用 Math.round 处理：
const num = 3.14159; const str = num.toFixed(2); // "3.14" const value = Number(num.toFixed(2)); // 3.14这两个小工具函数就是很好的外部脚本素材——把它们放进utils.js里，任何页面都能直接复用，这正是外部文件的优势体现。
6. 新手必看的常见问题与排查实录
6.1 为什么我的 JS 一点效果都没有
这是新手提问区的高频问题。绝大多数情况下，答案是这四种之一：
- 脚本压根没执行。比如外部文件 404，或者保留字报语法错误导致整个脚本被丢弃。
- 执行时 DOM 还没准备好。脚本在
head里，却直接操作了body中的元素。 - 事件绑定元素选错了。
getElementById的字符串拼接有误，或者页面里存在多个相同 id。 - 控制台有报错但你没看。很多时候不是没效果，是脚本在某一行中断了。javascript 运行时报错不解决，后面的代码全部不会执行，这是新手最需要建立的意识。
遇到问题先打开控制台，不要急着看代码逻辑。控制台没报错，再检查 DOM 选择器。这个习惯一旦养成，你能省下大量时间。
6.2 重复引用与全局变量污染问题
同一页面引用了两个外部脚本，两个脚本里都声明了let data，它俩实际上会共用一个全局作用域。后声明的覆盖先声明的，于是前一个脚本的逻辑可能全部失效。
之前我带的一个新人，就是这样排查了一个下午：一个页面引了公共库和自己的业务脚本，公共库里有个util对象，业务脚本里也定义了一个同名util，结果公共库里依赖util的函数全挂了。所以我的建议是：如果还在用传统方式写脚本，尽量把所有变量都包在一个独立的命名空间里，或者至少用 IIFE（立即执行函数）把作用域隔离起来：
(function() { // 这里的变量不会污染全局 const msg = 'hello'; console.log(msg); })();等你后面学了 ES Module，这种问题才能从根上解决。
6.3 缓存导致的“改代码却不生效”疑案
本地开发时改完 JS 刷新页面，发现还是旧效果，多半是浏览器缓存。普通刷新和强制刷新（Ctrl+F5）效果不同，后者会绕过缓存重新拉取资源。也可以打开控制台，在 Network 面板勾选 Disable cache，这样开发时更省心。
部署到服务器之后，这个问题也一样存在。比较常见的做法是给脚本 URL 加个版本参数：
<script src="./js/app.js?v=20250101"></script>这样改动代码后更新版本号，浏览器会把它当成新文件重新加载，缓存问题就能解决。很多工程化打包工具会自动帮你生成带 hash 的文件名，本质上都是同一种思路。
7. 最后分享一点我的真实体会
教了这么多年前端基础，我越来越觉得“代码写在哪”这个问题，比很多花哨的语法更能检验一个人有没有真正理解页面运行机制。它牵扯到 DOM 解析顺序、作用域、缓存、模块化，几乎每一个方向都能伸展开去。很多同学前三个月写代码遇到的大部分问题，追根溯源都能回到今天讨论的这几个概念上。
如果你想系统地练一练，我建议你做一个最简单的页面：一个按钮、一段文本、一个外部 JS 文件。先用外部文件方式实现点击按钮改变文本，再把同样逻辑改成内部脚本，最后体验一下行内写法坑在哪里。三种方式各写一遍，你的体感会完全不同。动手之后你会发现，这些知识不需要背，只要亲手踩过一次坑，比谁讲都管用。
