作为一名在代码世界里摸爬滚打的前端工程师，我们对于那个黑色的控制台窗口总是怀着一种极其复杂的感情。一方面它是我们排忧解难的神兵利器，报错信息、网络请求、DOM结构，一切尽在掌握；但另一方面当它被别有用心的用户打开时我们的代码逻辑、接口地址甚至核心算法就可Neng赤裸裸地暴露在阳光下。

你是否也曾有过这样的焦虑：辛辛苦苦写出的页面逻辑，被别人轻轻松松通过F12kan个底掉？或者担心有人通过控制台修改本地数据，绕过验证逻辑？这种想法虽然有点像是增加一点逆向门槛确实是有必要的。今天我们就来聊聊这个充满争议的话题——如何通过技术手段给用户打开控制台设置一些“路障”。

我们要明白，绝大多数普通用户打开控制台的路径通常只有两条：要么是习惯性地点击鼠标右键，选择“检查”；要么是直接按下键盘上的F12键。对于这部分“入门级”的探索者，我们完全Ke以通过拦截事件来劝退。

当我们在网页上随意点击右键时通常会弹出一个包含“检查”、“查kan源代码”等选项的菜单。这无疑是通往控制台的一扇便捷大门。既然如此，我们不妨直接把这扇门焊死。

通过监听全局的 contextmenu 事件，我们Ke以轻松阻止默认行为。这就像是给页面穿上了一件“防弹衣”，让右键菜单无处遁形。

document.addEventListener);

加上这段代码后用户确实Neng起到立竿见影的效果。当然这只是第一步，对于那些键盘流高手来说这根本不算什么。

除了右键，键盘快捷键才是老手们的Zui爱。F12、Ctrl+Shift+I、Ctrl+Shift+C、Ctrl+U，这些组合键就像是通往后台的暗号。

为了封堵这些漏洞，我们需要在 keydown 事件上Zuo文章。我们需要监听每一次按键，判断是否触发了这些“禁忌”的组合。一旦发现目标，就立即使用 preventDefault 将事件扼杀在摇篮里。

document.addEventListener("keydown", e => {
    // F12
    if  {
        e.preventDefault;
        return;
    }
    // Ctrl+Shift+I 
    if  {
        e.preventDefault;
        return;
    }
    // Ctrl+Shift+C 
    if  {
        e.preventDefault;
        return;
    }
    // Ctrl+U 
    if  {
        e.preventDefault;
        return;
    }
});

这样一来常规的“物理攻击”路径就被切断了。用户再想通过这些快捷键打开控制台，那可就没那么容易啦。不过别高兴得太早，道高一尺魔高一丈，还有geng隐蔽的方式等着我们去应对。

Ru果说禁用快捷键是“物理防御”，那么接下来我们要聊的就是“魔法防御”了。有些技术大牛根本不需要按F12，他们可Neng通过浏览器菜单栏的“geng多工具”进入开发者模式，或者直接修改浏览器设置。对于这种“降维打击”，前面的拦截手段显得有些力不从心。

既然无法直接监听浏览器菜单的点击事件，我们只Neng换个思路——猜测。我们Ke以通过检测页面运行状态的变化，来推测用户是否打开了控制台。

这是一种非常“流氓”但也极其有效的手段。它的核心思想是：既然你要调试，那我就让你永远停留在断点处，无法进行下一步操作。

我们Ke以利用 setInterval 定时器，不断地触发 debugger 语句。为了防止对方直接禁用断点，我们还Ke以动态构造这个函数。一旦控制台被打开，页面就会不断进入断点调试状态，卡死在当前行，让页面变得几乎不可用。

 => {
    function block {
        setInterval => {
            {return false;});
        }, 50);
    }
    try {
        block;
    } catch  {}
});

这段代码就像是一个不知疲倦的守卫，每50毫秒就检查一次。对于想通过控制台修改逻辑的人来说这无疑是一场噩梦。除非他们Neng精准地找到这段代码并绕过它，否则只Neng面对一个卡死的页面。

通常默认情况下浏览器控制台是在页面内靠边打开的。这意味着，一旦控制台被拉出，页面的可视区域就会发生变化，或者浏览器窗口的整体尺寸与可视尺寸产生差异。

这就是我们的切入点。我们Ke以监听 resize 事件，时刻盯着窗口大小的变化。Ru果检测到尺寸发生了异常波动，且不是全屏切换导致的，我们就Ke以大胆推测：用户可Neng正在打开控制台！

let lastWidth = window.innerWidth;
let lastHeight = window.innerHeight;
window.addEventListener => {
  const widthDiff = Math.abs;
  const heightDiff = Math.abs;
  // Ru果窗口尺寸变化但不是全屏切换，可Neng是控制台打开
  if  && !isFullScreen) {
    //跳转到空白页面
    window.location.href = "about:blank";
    alert;
  }
  lastWidth = window.innerWidth;
  lastHeight = window.innerHeight;
});
function isFullScreen {
  return (
    document.fullscreenElement ||
    document.webkitFullscreenElement ||
    document.msFullscreenElement
  );
}

通过监听页面大小变化来简单判断是否打开控制台，监听到打开后直接跳转到空白页面。这种策略虽然有些激进，但在某些对安全性要求极高的内部系统中，也不失为一种Zui后的倔强。

聊了这么多“花里胡哨”的手段，是时候泼一盆冷水了。虽然我们Ke以通过这些技术手段，给用户打开控制台设置重重障碍，但对于经验老到的用户而言，绕过这些限制并非难事。

这就好比是你把家里的门锁换了三道，但对于专业的开锁匠来说可Neng只需要一根铁丝就Neng搞定。依赖前端技术拦截控制台访问，本质上是一种“防君子不防小人”的策略。用户完全Ke以禁用JavaScript、使用无头浏览器、或者直接通过抓包工具来绕过页面的限制。

geng有甚者，现在市面上还有像 console-ban 这样的npm包，专门用来帮助开发者geng容易地实现阻止打开控制台的功Neng。但无论工具多么强大，dou无法改变一个事实：前端的安全永远是相对的。

Ru果你真的想保障自己网站的安全，不要把希望寄托在拦截控制台上。真正的安全防线应该建立在后端：严格的参数校验、完善的权限控制、数据加密传输……这些才是王道。前端所Zuo的这些拦截，geng多是为了增加一点点逆向成本，或者防止小白用户的误操作，而不是为了构建一个坚不可摧的堡垒。

写到这里我不禁想起平时写代码的日子。有时候为了一个bug抓耳挠腮，有时候为了一个巧妙的设计沾沾自喜。我们今天讨论的这些“阻止打开控制台”的方法，其实就像是开发者和用户之间的一场趣味博弈。

虽然我们无法完全禁止用户打开浏览器控制台或修改页面的代码逻辑，但采取一些措施来增加用户的难度和降低滥用的风险，在某些特定场景下依然是有价值的。无论是禁用F12、阻止默认行为，还是监听窗口变化，每一行代码背后dou藏着开发者的“小心思”。

🎉 这里是 JYeontu，现在是一名前端工程师，有空会刷刷算法题，平时喜欢打羽毛球 🏸 ，平时也喜欢写些东西，既为自己记录 📋，也希望Ke以对大家有那么一丢丢的帮助，写的不好望多多谅解 🙇，写错的地方望指出，定会认真改进 😊，偶尔也会在自己的公众号『前端也Neng这么有趣』发一些比较有趣的文章，有兴趣的也Ke以关注下。在此谢谢大家的支持，我们下文再见 🙌。

发送 加群 还Ke以加入群聊，一起来学习吧~