企业官网建设流程全解析

说实话，前端里没有哪个标签像a标签这样“天天见、天天被用错”。一说到禁用a标签跳转页面或定位链接，绝大多数人第一反应就是写href="#"或者href="javascript:void(0)"，然后在 onclick 里返回一个false。这个做法在十年前确实能跑，但它带出来的隐藏问题比它解决的问题还多：点完之后地址栏多一个#、页面可能偷偷滚到顶部、在单页应用里直接把路由打乱、用户右键复制链接复制出一段“javascript:void(0)”……每一条都够闹心。

这篇东西不是给你背属性的，我想把“禁用 a 标签”这件事彻底拆开：先搞清楚 a 标签到底跳的是什么，再逐个拆解各种写法的坑，然后重点讲“定位链接”这种特殊场景怎么做，最后我会把项目里真正在用的封装方案和踩过的坑一次性倒出来。新同学可以从头看到尾，老前端也可以重点扫第三、四章，有些边界问题你八成也遇到过。

1. a标签的默认行为到底是什么：三种“跳转”必须分清

1.1 浏览器眼中的“跳转”不只有换页面

很多人把“a 标签跳转”和“页面跳转”画等号，这是第一步就错了。浏览器处理href属性的默认行为，粗略分有三种。

第一种是常规页面导航，比如href="https://example.com"或者href="/detail?id=1"，点击后浏览器卸载当前页面，加载新地址。这种情况最常见的禁用诉求是：表单没填完不许走、菜单当前项不可点、或者外链需要先经过一道确认。

第二种是锚点定位，也就是href="#section"这种写法。注意，它本质上不是“导航到另一个文档”，而是在当前文档里找一个id="section"的元素，然后滚动到它所在的视口位置，同时把#section写进地址栏。这种“定位链接”在单页站、长列表页里非常常见，禁用它的诉求也五花八门：不想让地址栏变丑、不想用默认的瞬间滚动、或者想自己控制滚动到某个局部容器而不是窗口。

第三种是协议类链接，比如mailto:、tel:、甚至javascript:这些以协议开头的内容。它们不是导航，而是触发某个外部动作。这类“跳转”有时候也想禁用，比如你想把邮箱地址显示成链接的样子，但不希望用户一点就拉起邮件客户端。

三种行为的默认处理机制完全不同，所以“禁用跳转”的手段必须是分层设计的：你不可能用一个办法同时管住页面导航、锚点定位和协议触发。搞清楚你面对的是哪一种，比急着写代码重要得多。

1.2 href缺省时的 a 标签其实不算链接

还有一个非常容易被忽略的事实：<a>标签在没有href属性的时候，从 HTML 语义上讲就不是一个链接。它不会进入 Tab 键的焦点序列，屏幕阅读器也不会把它读成链接，浏览器对它的唯一“默认行为”就是没有任何默认行为。

这带来一个反直觉的结论——如果你想彻底禁掉一个 a 标签的所有跳转行为，最朴素的办法其实是把href删掉，而不是去拦截事件。但很多人不敢这么干，是因为删了href之后样式会变：手型光标没了、下划线也没了，看起来就不像一个可点击的东西。这个“看起来不像”的问题恰恰说明，你对这个元素本身的定位就是模糊的。

所以我每次做技术方案之前都会先逼问自己一个问题：这个交互，到底是“链接”还是“按钮”？是链接，就保留href，通过禁用态来控制；不是链接，就是按钮，应该用<button>而不是在一张错误骨架上缝缝补补。这个问题想明白了，后面所有写法的取舍都会清晰很多。

1.3 禁用前必须想清楚的“边界条件”

除了“链接还是按钮”，另外两个边界条件也决定你选哪种实现：键盘可达性和 SEO 语义。

先说键盘。<a>不管有没有href，它都是可以用键盘 Enter 键激活的（有 href 时在 Tab 序里；无 href 时编程式聚焦后 Enter 依然可以触发）。你用 CSS 把鼠标点击禁掉了，键盘用户按 Tab 到链接上按回车，照样跳转。很多“禁用”方案都在这一点上翻车。

再说爬虫和复制链接。搜索引擎会把href当作文档真实出链来抓取，你写href="javascript:void(0)"，看起来页面里有一颗外链，但抓下来是无效地址；用户想转发你的页面时右键复制链接，复制的也是那串丑陋的javascript:。这些都不是“能用就行”的性能问题，而是实打实的可用性问题。

所以，禁用方案必须至少覆盖三层：鼠标点击、键盘激活、辅助技术感知。少一层，都会在某个角落出事故。

2. 最常被踩坑的三种禁用写法：#、javascript:void(0)与return false

2.1href="#"+return false：第一代“经典坑”

我入行那会儿，几乎所有“禁跳转”代码都是这么写出来的：

<a href="#" onclick="return false;">禁用链接</a>

它为什么能工作？因为在浏览器的事件模型里，onclick这个行内事件处理器如果返回false，就等价于调用了event.preventDefault()，浏览器随后检查这个事件没有被取消，才会执行默认的导航或定位动作。所以return false实际上拦截的是“默认行为”。

但它的副作用也相当直白。当用户点下这个链接时，默认行为虽然被拦截了，可如果哪一天事件监听链路上出了岔子、或者有一条脚本报错被截断了，return false没执行到，浏览器就会按照href="#"的本意去做两件事：第一，把当前页面滚到顶部，因为#会被解析成一个空锚点；第二，往地址栏塞一个#或修改现有 hash。

在普通页面里，你顶多看到页面闪一下顶部，这还能忍。可如果你在一个 hash 路由的单页应用里，比如 Vue Router 的 hash 模式或老式 Backbone 路由，这个#会被路由直接吞掉，变成一次无意义的页面切换甚至误导航。我在项目里就遇到过线上页面突然跳到首页，最后排查出来是一段第三方脚本在href="#"的链接上多绑了一个事件，把return false给覆盖了。

更不要提一个细节：href="#"的链接在按住 Ctrl/Cmd 点击时，浏览器会尝试在新标签页打开当前页 + #，这个行为同样不受onclick="return false"控制。你要禁的东西，它反而在另一个入口放行了。

2.2href="javascript:void(0)"：能用，但副作用一个没少

href="javascript:void(0)"是比href="#"看起来“更干净”的写法，因为它至少不会篡改地址栏，也不会滚回顶部。void(0)的作用是让这个 JavaScript 表达式返回undefined，这样浏览器不会拿一个返回值来替换当前文档。直接把href写成javascript:;也是一个意思，只是更短。

我可以负责任地说：这个方案“能用”，但它属于典型的“能用和好用之间差着十个量级”。

第一个问题是 SEO 和出链语义。搜索引擎在提取页面链接时会读取href字段，javascript:void(0)会被判定为无效出链。你可以看一下自己站点的数据：所有用这种写法的内链，在搜索引擎后台基本都处于“抓取异常”状态。第二个问题是用户复制链接。用户在手机上长按、在电脑上右键，想复制这个链接，复制的就是这串javascript:void(0)，完全没意义。第三个问题比较隐蔽：在启用了内容安全策略（CSP）的站里，内联的javascript:协议地址可能直接被策略拦截，导致这个 href 从一个“伪链接”变成一个彻底无效的链接。

还有一件事我得单独提：href="javascript:void(0)"在中键点击或 Ctrl+点击时，浏览器有时会尝试在新标签页打开这段“伪地址”，表现因浏览器而异，但你已经完全没有控制权了。

2.3onclick="return false"与addEventListener的行为差异

可能有人会说，前面那些坑我认，但我把return false写在事件里总没问题吧？这里又有一个常见的误解。

return false只对行内onclick这种“内联事件处理器”有效。它起作用的底层原因是：浏览器执行内联事件处理器时，会对函数的返回值做一次判断，false会被转成取消默认动作的信号。但addEventListener注册的回调函数，返回值是没有人读的，你写一百个return false也没有任何效果。

// 这样写是无效的 document.querySelector('#link').addEventListener('click', function () { // 这里的 return false 不会阻止浏览器跳转 return false; }); // 必须显式调用 preventDefault document.querySelector('#link').addEventListener('click', function (event) { event.preventDefault(); });

这个差异我见过太多人栽跟头：页面用了现代的事件绑定方式，但脑子里还停留在老一套 “return false” 的思路里，结果链接永远拦不住。你要记住一件事：用addEventListener，就老老实实调preventDefault()；用 jQuery 的话，return false内部会被 jQuery 转成preventDefault + stopPropagation，但在原生 JavaScript 里没有这个待遇。

顺带说一句：当你调用了preventDefault之后，event.defaultPrevented会变成true，浏览器在触发默认行为之前会检查这个标志。某些 UI 框架（比如 Vue 的事件修饰符.prevent）本质上就是在做同一件事，只是帮你在语法层包装好了。

3. 从根上“禁”掉：删除href、button替代与pointer-events的边界

3.1 删除href：彻底，但要补可访问性的课

回到第一节说的那个点：没有href的<a>本来就不会跳转，也没有定位行为。所以对“本来就不该是链接”的元素，最干净的手段是删除href。

<a class="menu-item">当前页所在项（不可点击）</a>

这个写法的好处是，从根上杜绝了所有默认行为：不会导航、不会改 hash、不会触发锚点定位、Ctrl+点击也没用。但如果你的产品经理还要求它“长得像能点的”，你需要手动补回视觉反馈：

a.menu-item { cursor: pointer; color: #1677ff; text-decoration: underline; }

不过要特别小心可访问性。删掉href之后，这个元素会从 Tab 焦点序列里消失，键盘用户根本走不到它；屏幕阅读器也不会把它当成链接来读，用户不知道这里有个可点区域。所以如果你删了 href，又希望它保持“可交互控件”的可用性，通常要自己补角色和焦点：

<a role="button" tabindex="0" class="menu-item" aria-disabled="true" > 正在加载中的菜单项 </a>

这样一来，它在辅助技术里是“禁用状态的按钮”，在键盘上可以被 Tab 聚焦（虽然禁用态通常不建议聚焦；更准确的做法是用tabindex="-1"保留编程式聚焦能力）。注意，role="button"只是语义声明，不会自动让它响应 Enter 键，所以通常还得在键盘事件里补一个回车触发的逻辑。这里我不打算展开太多，因为把<a role="button">的键盘一致性做完整，代码量已经接近直接把标签换成<button>了。

3.2 改用button：语义上最“正确”的替代

如果这个元素本来就是在“执行一个动作”，比如展开菜单、打开弹窗、提交内容，那正确写法是<button>，而不是想尽办法让<a>看起来像按钮。按钮的天然语义就是“可点击、可触发动作”，它没有href，不存在“跳转页面的默认行为”，更不存在“定位链接”这种说法。你要禁用它，直接写原生disabled属性就行，浏览器会顺带帮你处理掉鼠标事件和键盘事件，屏幕阅读器也会自动读成“已禁用”。

<button type="button" disabled>正在加载</button>

这里有一个魔鬼细节：<button>如果不写type，在表单里默认是submit，点击会触发表单提交，这等于换了一种突变方式“跳转”。所以我写按钮的第一习惯就是永远显式写type="button"。因为很多人把 a 标签替换成 button 之后，发现页面一刷新、表单被提交了，问题不在标签替换本身，而是 type 默认值。

不管使用哪种写法，我都要专门提醒一个键盘层面的事情：无论你用的是删除 href、role="button"还是伪装的 button，只要这个元素还保留在 Tab 序列里，用户按 Enter 键都会触发合成点击事件。所以“禁用”状态绝不能只靠 CSS 或只靠语义，必须让事件处理代码也感知到禁用态。

3.3pointer-events: none：只会禁掉半边天

再来看一个非常流行的 CSS 禁用大招：

.is-disabled { pointer-events: none; cursor: not-allowed; opacity: 0.6; }

pointer-events: none确实能在一瞬间把鼠标/触摸的点击事件全部屏蔽掉，配合半透明和光标样式，视觉上特别像“禁用”。但它有一个致命的边界：它只对指针设备生效。键盘用户用 Tab 聚焦到这个链接再按回车，浏览器依然会执行正常的跳转，因为键盘激活走的是“合成点击事件”，不受 CSS 控制。

所以pointer-events: none只能作为“视觉禁用 + 鼠标禁用”这一层，绝不能当作完整的禁用方案。完整的组合是：

<a href="/somewhere" class="is-disabled" tabindex="-1" aria-disabled="true" >a.is-disabled, a.is-disabled:link, a.is-disabled:visited { pointer-events: none; cursor: not-allowed; opacity: 0.6; }

tabindex="-1"把链接移出 Tab 序列，键盘到不了；aria-disabled="true"告诉屏幕阅读器“这是禁用的”；>.is-disabled .tooltip-content { pointer-events: auto; }

否则你会在某个深夜接到“为什么那个提示框死活点不动”的工单。

4. 专治“定位链接”：阻止锚点跳动又不丢功能的完整方案

4.1 锚点定位到底触发了哪些默认行为

现在来到标题里“定位链接”的部分。href="#targetId"这种写法，浏览器会做三件事：

1. 在当前文档中查找id="targetId"或name="targetId"的元素；
2. 将该元素滚动到浏览器视口内（默认是瞬间定位到顶部）；
3. 把#targetId写入地址栏，并触发一次hashchange事件（如果 hash 有变化）。

你要“禁用定位链接”，必须先想清楚要废掉哪一步。如果你只希望它不瞬间滚动，而地址栏的 hash 保留不保留、hashchange触发不触发，都是可以拆开的。很多人一刀把preventDefault()写上，滚动没了，hash 也没了，看起来“禁用成功”，实际上把“跳转到评论区”这个功能整个废掉了，用户点击后没有发生任何事，这是典型的过度禁用。

4.2 拦截默认滚动并换成自定义平滑定位

最常见的诉求是：保留“点击后跳到目标位置”的功能，但不要应用浏览器默认的瞬间定位，而是自己想要平滑滚动。这种情况下不要禁用整个锚点功能，只需要在点击时取消默认行为，然后手动滚动到目标元素：

<a href="#comments" class="js-smooth-anchor">跳到评论区</a>

document.querySelectorAll('.js-smooth-anchor').forEach(function (link) { link.addEventListener('click', function (event) { var href = this.getAttribute('href'); if (!href || href.charAt(0) !== '#') return; var target = document.getElementById(href.slice(1)); if (!target) return; event.preventDefault(); if (typeof target.scrollIntoView === 'function') { target.scrollIntoView({ behavior: 'smooth', block: 'start' }); } else { // 老旧浏览器兜底 target.scrollIntoView(true); } }); });

这段代码的精髓在于preventDefault的位置：先解析并找到目标元素，确认目标存在，才去禁用默认行为。如果目标不存在，直接放行，让浏览器自己处理，用户不至于点了没反应。我见过很多人把preventDefault()无条件写在第一行，结果目标 id 写错了也毫无提示，链接变成死链。

还有一个容易被忽略的细节：scrollIntoView滚动的是“所有能够滚动的祖先容器”，不是只滚 window。如果目标元素在某个overflow: auto的局部容器里，scrollIntoView会把那个容器也一起滚到位，这比手动计算offsetTop要省事得多。但如果你的需求是只滚主窗口、不滚内层容器，就得自己用getBoundingClientRect()计算位置，再设置对应容器的scrollTop。两个方案的取舍很简单：局部容器是用户预期的滚动主体，用scrollIntoView；必须从页面级坐标计算，用getBoundingClientRect。

4.3 只改hash但不滚动的“伪定位”

另一种情况更反直觉：我希望点击链接后地址栏变成#comments，但页面完全不要滚动到评论区。典型场景是“分享当前模块给朋友”的复制链接按钮：你想让链接里带上位置信息，又不想打扰用户当前的阅读位置。

这时候不能简单preventDefault，因为preventDefault会把 hash 的修改一起取消掉。正确做法是取消默认行为之后，手动用history.pushState或history.replaceState修改 URL 状态：

link.addEventListener('click', function (event) { var hash = this.getAttribute('href'); // 例如 "#comments" event.preventDefault(); history.replaceState(null, '', hash); });

replaceState和pushState的区别在于：前者不会在浏览历史里新增记录，用户按后退不会回到上一个 hash；后者会新增一条历史。绝大多数“只想改地址栏、不想跳动”的场景，我推荐用replaceState，因为它更像“原地更新状态”，不会扰乱用户的前进后退预期。

这里同样有个细节：history.pushState修改 hash 时，不会触发hashchange事件，也不会引发滚动。如果你依赖hashchange去做一些统计或者状态同步，需要手动派发一个自定义事件，或者直接调用你自己的状态回调。反过来，如果你确实希望hashchange触发，但不想滚动，可以先preventDefault再手动location.hash = hash，不过这样会让页面产生一条历史记录，两种做法按需取舍。

4.4 在Vue/React中禁用“定位链接”的注意点

框架环境下，“定位链接”往往不是单纯的href="#id"，而是被路由系统劫持的。比如 Vue Router 的 hash 模式会把href="#/path"当作路由地址；React 里你可能用了<Link to="/path">这种封装组件。这时“禁用跳转”要分两层：一是组件层语义禁用，二是事件层拦截。

Vue 写法里，我见过最干净的处理是给router-link加一个自定义 class，通过点击事件阻止默认行为并且不让路由接管：

<router-link to="/detail" class="is-disabled" >function onDisabledClick(event) { if (event.currentTarget.dataset.disabled !== 'true') return; // 这里已经由 .prevent 阻止了默认行为，只需做提示 console.log('该入口暂不可用'); }

需要注意的是，Vue 路由的跳转通常被绑定在更外层的根节点上，光靠@click.prevent能不能彻底拦住取决于路由库的监听方式。多数情况下.prevent足够，因为它直接禁止合成点击的默认动作；如果遇到路由还是要跳，再考虑在事件回调里临时加event.stopPropagation()。但stopPropagation是双刃剑——你可能会把父级其他合法事件的传播也一起扼杀，所以只能当作最后手段。

React 里类似，Link的onClick里调用preventDefault：

<Link to="/detail" onClick={(event) => { if (disabled) { event.preventDefault(); } }} > 详情 </Link>

但 React 的Link默认渲染成<a>，如果你给了一个disabledprop，不少 UI 库并不会真的禁止键盘操作，最后还是得靠tabIndex={-1}和aria-disabled收尾。换句话说，框架帮你封装了跳转逻辑，却没帮你封装禁用逻辑，这块始终是自己的事。

5. 把禁用逻辑封装成工具：三个实战场景一起解决

5.1 一个始终可用的“安全禁用”工具函数

鉴于上面提到的坑，我在实际项目里会封装一个“安全禁用处理器”，核心逻辑就是一句话：任何形式触发的点击，只要元素处于禁用态，就无条件取消默认行为，并且阻止它冒泡到不该冒泡的地方。它不用管这个 a 标签是普通链接、锚点定位还是框架路由链接，只要>function bindSafeDisabled(root = document) { root.addEventListener('click', function (event) { var disabledTarget = event.target.closest('a[data-disabled="true"], button[data-disabled="true"]'); if (!disabledTarget) return; // 取消跳转/定位/表单提交等默认行为 event.preventDefault(); // 可选：阻止事件继续冒泡，避免路由库在父级捕获后触发跳转 // 注意：除非明确知道会影响什么，否则不建议无条件使用 // event.stopPropagation(); }); } bindSafeDisabled();

我特意用了事件委托而不是给每个链接单独绑定，原因有两个：第一，动态渲染出来的链接不需要重新绑事件；第二，禁用状态经常会变，委托模式只需要读取 DOM 上的><a href="/orders/list" class="nav-link" ><a href="/step2" id="nextStepLink" > 下一步 </a>

document.getElementById('nextStepLink').addEventListener('click', function (event) { var form = document.getElementById('step1Form'); if (typeof form.reportValidity === 'function' && !form.reportValidity()) { event.preventDefault(); // 浏览器已经自动提示第一个非法字段，这里只需记录日志或统计 console.log('表单校验未通过，跳转已被拦截'); } });

reportValidity()是原生表单校验 API，它会触发浏览器内置的“请填写该字段”气泡提示，同时把焦点移到第一个不合法的输入项。比手动收集错误信息再setCustomValidity要省心得多，主流浏览器都支持。要注意的是，如果表单里的某个字段是自定义组件（比如日期选择器、富文本编辑器），原生校验覆盖不到，你得在点击回调里跑自己那套校验逻辑，再把event.preventDefault()挂上。

5.4 场景三：防止重复点击造成重复提交

a 标签没有原生disabled，所以在“提交后防二次点击”的场景里，很多人会临时用pointer-events: none硬禁。但双击产生两次点击事件的速度，比 CSS 重绘还要快，pointer-events未必来得及生效。我在实战中更信得过状态锁：

var isSubmitting = false; submitLink.addEventListener('click', function (event) { if (isSubmitting) { event.preventDefault(); return; } isSubmitting = true; this.setAttribute('data-disabled', 'true'); this.classList.add('is-submitting'); this.setAttribute('aria-disabled', 'true'); this.setAttribute('tabindex', '-1'); doRealSubmit() .catch(function () { // 失败时恢复可点状态 isSubmitting = false; submitLink.removeAttribute('data-disabled'); submitLink.classList.remove('is-submitting'); submitLink.removeAttribute('aria-disabled'); submitLink.setAttribute('tabindex', '0'); }); });

别忘了isSubmitting在失败之后的恢复逻辑。很多人把状态锁写死了，接口报错后链接依然是禁用态，用户连重试的机会都没有。恢复动作里记得把tabindex一并改回0，否则键盘用户永远到不了这个链接。

6. 方案对照与我的落地习惯

6.1 常用禁用方案速查表

我把做技术评审时最常用的一张对照表留在这里，新同学可以把它存着：

这张表的核心结论是：没有一种方案能靠单一手段覆盖所有入口。真正稳妥的“禁用”从来是组合拳：CSS 管视觉和指针，tabindex管键盘焦点，aria-disabled管辅助技术，JS 永远做最后一道司法拦截。

6.2 我最常用的“决策链路”与踩坑记忆

最后分享一条我从无数次返工里总结出来的决策链路，也是我现在每次写相关代码前都要过一遍的内心 OS。

第一步，问自己：它是不是链接？如果它只是执行动作，直接换<button>，没有任何后续烦恼。第二步，如果是链接：这个链接在“禁用态”之外还有没有真实的可用场景？有，就保留真href，维护一套禁用态；没有，说明它在产品逻辑里本来就不是跳转入口，请回到第一步。第三步，禁用态必须同时处理鼠标、键盘、辅助技术三层，每一层都不能缺席。第四步，如果你的链接涉及锚点定位，先搞清楚你要禁的是“滚动”还是“hash 变更”，两者可以分开控制。

说到踩坑记忆，有两次教训我特别想提。第一次是把pointer-events: none加在一个父级菜单容器上，结果子菜单的 tooltip 怎么都点不到，排了一下午队才发现是继承生效，最后在子元素上补了pointer-events: auto才解决。第二次是在 Vue Router 的 hash 模式下用href="#"做了一个“返回顶部”的占位链接，上线后用户每次点它都会从当前详情页弹回列表页，因为路由库把那个#当作了一次路由变化。那次之后，我再也不在单页应用里使用任何裸href="#"。

说白了，“禁用 a 标签跳转页面或定位链接”从来就不是一行代码的事，它是一个需要你同时理解 HTML 默认行为、CSS 边界、键盘事件模型和语义化的小系统工程。把这几层想清楚，再去写代码，你会发现那些“为什么禁不掉”的诡异 bug，大部分都能提前死在设计阶段。