<i id='54B47013A7'><strike id='54B47013A7'><tt id='54B47013A7'><time date-time="87d601"></time><tt dir="349e67"></tt><var lang="02bc9c"></var><pre date-time="7ed845" id='54B47013A7'></pre></tt></strike></i> Hello ，不随便使大家好 ，用陌我是生人 Sunday 。
这段时间 ，推码经常能在秋招群看到有人发 ：“要内推吗 ？坑多这是我的码 ，直接填就行 。不随便使”
乍一看 ，用陌好像是生人捷径 。填上就能绕过网申 ，推码HR更快看到简历 ，坑多简直不要太香 。不随便使
但真相是用陌 ：随便乱填【陌生人】的建站模板内推码 ，坑会比你想的生人多。 。推码。坑多
想要知道原因 ，咱们得先想清楚 你为什么想要内推码？
招聘 ，说白了就是一场 人才筛选的过程 。
同一个岗位 ，几千份简历同时涌进来 ，HR 每天就几个小时能看 ，你的简历很可能直接淹没在系统里。
这时候 ，免费模板内推码能起的作用就是 ：让你的简历不至于那么快沉下去 。在某些公司里 ，带内推的候选人会被标个“推荐”标签（注意 ，这只是某些厂而异） ，HR 筛简历时 可能会 优先看 。
而且 ，如果内推人和你熟 ，他还能帮你盯一下进度 ：
简历到底过没过初筛 ？卡在了哪一关 ？有没有机会补材料或者转岗 ？所以说 ，内推码肯定是有价值的。云计算但是 ，它的价值仅局限在 让你可以知道你当前的进度到底到哪了 ，同时有一点可能增加你的简历被看到的概率。
至于网上传说的 ：“有了内推码 ，你入职的概率就会大大增加 。” 这是 纯扯淡 的 ！
明白了内推码的作用 ，那么为什么【陌生人】的内推码没用呢 ？
问题就出在【陌生】上 。内推的价值不是那个“码”，而是推荐人愿不愿意为你背书 ，为你跟踪进度 。
陌生人不会帮你查流程 ，更不会替你和HR沟通 。
并且，很多公司的内推系统里常常会有选项 ：“推荐人是否认识候选人？”
陌生人只能选“不认识” ，源码下载这反而让你在HR眼里是 低优先级 。
更现实一点 ，有些人发码只是为了薅积分 、冲KPI，你对他来说只是一个“数字” ，投完就完事了 。
并且 ，还有一个 大坑 就是 ：校招大部分都会有“投递限制” 。既 ：投递的岗位数量 、次数 是有限的服务器租用。
如果你是用了陌生人的内推码 ，那么假如 ：
你一开始投递了 软开岗 ，后来发现自己更适合前端岗 。想改投的时候 ，却发现投递额度已经用完了 。
如果想要改投递岗位 ，你发现连 内推人 是谁你都不知道 ，简历就只能长时间泡池子了 。
所以 ，使用【陌生人】的内推码 ，你以为自己走了捷径 。其实很有可能只是白白消耗了一次投递机会。意义并不大。
说到底 ，内推不是靠一个“码” ，而是靠“人”。
靠谱的内推，能让你的简历真正“被看见”，还能帮你争取额外机会 。那什么时候填内推码才值得呢 ？
熟悉的直系学长学姐 ：他们最懂校招的节奏，也更愿意帮忙跟进 。比如 ，你卡在笔试环节 ，学长可能直接帮你打听到是“代码风格问题”还是“题目没过线” ，这比你自己瞎猜靠谱多了 。朋友或同事介绍 ：哪怕不是同专业 ，只要对方真认识你 ，愿意说一句“这人靠谱” ，HR对你的印象分都会不一样 。校园大使/校招宣讲会 ：很多公司会指定校园大使 ，他们手里的内推渠道就是官方的 ，并且你也可以联系到他 。确认过身份的在职员工比如通过牛客 、LinkedIn 找到认证的企业员工，能确定对方是真在岗 、愿意帮忙 ，这种内推才是正经能走通的 。简单说 ：内推码有用的前提 ，是推荐人愿意为你背书 ，而不是单纯“给你个码” 。
那么最后 ，老规矩，咱们来看两道前端大厂面试常见的面试问题 ：
简单理解 ，就是攻击者往页面里塞了恶意的 JS 脚本 ，然后让这段脚本在用户的浏览器里跑起来 。
常见的做法比如在评论区插入一段 <script>alert(你被黑了)</script> ，如果后台没做过滤 ，别人一打开这条评论，这个脚本就执行了 。
XSS 的本质是“用户输入能当脚本跑了”，所以关键就是输入要过滤 ，输出要转义。
输出转义：比如后端模板渲染时把 < 转成 <，这样就不会被当成标签执行 。输入校验 ：比如评论区只能输入文字 ，不允许直接带 <script> 。CSP（内容安全策略） ：通过响应头 Content-Security-Policy 限制哪些脚本能跑 ，尽量只允许本域脚本 。HttpOnly Cookie ：就算页面有 XSS ，脚本也拿不到 cookie 。它利用的是用户“已经登录过”的状态。
比如 ：我在购物网站已经登录了，攻击者发给我一个钓鱼链接 ，我一不小心点开 ，页面偷偷帮我发起一个“转账请求” 。由于浏览器会自动带上我的 cookie ，后端以为是我自己点的 ，就执行了。
而这个问题的核心就是 ：后端只校验了 cookie/session ，没有校验请求是不是用户主动发起的 。
CSRF 的问题在于“浏览器自动带 cookie” ，所以要让攻击者没法伪造一个合法请求。
CSRF Token ：后端生成一个随机 token ，前端每次请求都带上 。攻击者拿不到这个 token ，就无法伪造请求 。SameSite Cookie ：把 cookie 设置成 SameSite=Strict 或 Lax ，这样第三方页面发请求时不会带上 cookie 。双重验证 ：比如转账这种操作 ，要求输入一次密码或验证码 ，就算点了钓鱼链接也没用。校验 Referer/Origin ：后端检查请求头来源是不是自己域名 。这个问题基本属于 浏览器渲染原理的必考点 。
给大家一段代码 ，这段代码展示了 重绘 和 回流 的场景 。
复制<div id="box"></div> <style> #box { width: 100px; height: 100px; background-color: red; } </style> <script> const box = document.getElementById(box); // 改宽度 ：会触发回流 + 重绘 setTimeout(() => { box.style.width = "200px"; }, 1000); // 改颜色：只触发重绘 setTimeout(() => { box.style.backgroundColor = "blue"; }, 2000); </script>1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.回流就是浏览器需要重新计算页面元素的 几何结构和布局 。
比如位置 、大小 、盒子模型这些东西一旦变了 ，浏览器得重新排版。
常见触发场景有 ：
改变元素的大小（width 、height 、padding、margin、border）。改变元素的显示状态（比如 display: none → block） 。DOM 结构的增删 ，或者位置变化 。获取一些需要最新布局信息的属性，比如 offsetHeight、getBoundingClientRect() ，这些都会强制触发回流 。重绘是浏览器已经知道元素的位置和大小没变 ，但需要重新画一遍样式 ，比如颜色 、背景 、阴影。它不用重新计算布局 ，只是重新绘制像素 。
常见触发场景有：
改变颜色（color 、background-color）。改变可见性（visibility: hidden） 。改变阴影（box-shadow） 。一个比较核心的面试区别点是 ：
回流一定会引起重绘 ，但重绘不一定回流 。回流开销更大 ，因为它会触发布局计算 ，性能影响比单纯的重绘要重 。 顶: 58踩: 35
评论专区