不要隨便使用陌生人的「內推碼」，坑很多...
Hello，大家好，我是 Sunday。
這段時間，經常能在秋招群看到有人發：“要內推嗎？這是我的碼，直接填就行。”
乍一看，好像是捷徑。填上就能繞過網申，HR更快看到簡歷，簡直不要太香。
但真相是：隨便亂填【陌生人】的內推碼，坑會比你想的多。。。
想要知道原因，咱們得先想清楚 你為什么想要內推碼？
內推碼到底有啥用？
招聘，說白了就是一場 人才篩選的過程。
同一個崗位，幾千份簡歷同時涌進來，HR 每天就幾個小時能看，你的簡歷很可能直接淹沒在系統里。
這時候，內推碼能起的作用就是：讓你的簡歷不至于那么快沉下去。在某些公司里，帶內推的候選人會被標個“推薦”標簽（注意，這只是某些廠而異），HR 篩簡歷時 可能會 優先看。
而且，如果內推人和你熟，他還能幫你盯一下進度：
- 簡歷到底過沒過初篩？
- 卡在了哪一關？
- 有沒有機會補材料或者轉崗？
所以說，內推碼肯定是有價值的。但是，它的價值僅局限在 讓你可以知道你當前的進度到底到哪了，同時有一點可能增加你的簡歷被看到的概率。
至于網上傳說的：“有了內推碼，你入職的概率就會大大增加。” 這是 純扯淡 的！
為什么【陌生人】的內推碼坑很多？
明白了內推碼的作用，那么為什么【陌生人】的內推碼沒用呢？
問題就出在【陌生】上。內推的價值不是那個“碼”，而是推薦人愿不愿意為你背書，為你跟蹤進度。
陌生人不會幫你查流程，更不會替你和HR溝通。
并且，很多公司的內推系統里常常會有選項：“推薦人是否認識候選人？”
陌生人只能選“不認識”，這反而讓你在HR眼里是 低優先級。
更現實一點，有些人發碼只是為了薅積分、沖KPI，你對他來說只是一個“數字”，投完就完事了。
并且，還有一個 大坑 就是：校招大部分都會有“投遞限制”。既：投遞的崗位數量 、次數 是有限的。
如果你是用了陌生人的內推碼，那么假如：
你一開始投遞了 軟開崗，后來發現自己更適合前端崗。想改投的時候，卻發現投遞額度已經用完了。
如果想要改投遞崗位，你發現連 內推人 是誰你都不知道，簡歷就只能長時間泡池子了。
所以，使用【陌生人】的內推碼，你以為自己走了捷徑。其實很有可能只是白白消耗了一次投遞機會。意義并不大。
什么時候用內推碼才真正有用？
說到底，內推不是靠一個“碼”，而是靠“人”。
靠譜的內推，能讓你的簡歷真正“被看見”，還能幫你爭取額外機會。那什么時候填內推碼才值得呢？
- 熟悉的直系學長學姐：他們最懂校招的節奏，也更愿意幫忙跟進。比如，你卡在筆試環節，學長可能直接幫你打聽到是“代碼風格問題”還是“題目沒過線”，這比你自己瞎猜靠譜多了。
- 朋友或同事介紹：哪怕不是同專業，只要對方真認識你，愿意說一句“這人靠譜”，HR對你的印象分都會不一樣。
- 校園大使/校招宣講會：很多公司會指定校園大使，他們手里的內推渠道就是官方的，并且你也可以聯系到他。
- 確認過身份的在職員工比如通過牛客、LinkedIn 找到認證的企業員工，能確定對方是真在崗、愿意幫忙，這種內推才是正經能走通的。
簡單說：內推碼有用的前提，是推薦人愿意為你背書，而不是單純“給你個碼”。
那么最后，老規矩，咱們來看兩道前端大廠面試常見的面試問題：
XSS、CSRF 攻擊的原理是什么？
先說 XSS（跨站腳本攻擊）：
簡單理解，就是攻擊者往頁面里塞了惡意的 JS 腳本，然后讓這段腳本在用戶的瀏覽器里跑起來。
常見的做法比如在評論區插入一段 <script>alert('你被黑了')</script>，如果后臺沒做過濾，別人一打開這條評論，這個腳本就執行了。
XSS 防御
XSS 的本質是“用戶輸入能當腳本跑了”，所以關鍵就是輸入要過濾，輸出要轉義。
- 輸出轉義：比如后端模板渲染時把
<轉成<，這樣就不會被當成標簽執行。 - 輸入校驗：比如評論區只能輸入文字，不允許直接帶
<script>。 - CSP（內容安全策略）：通過響應頭
Content-Security-Policy限制哪些腳本能跑，盡量只允許本域腳本。 - HttpOnly Cookie：就算頁面有 XSS，腳本也拿不到 cookie。
再說 CSRF（跨站請求偽造）：
它利用的是用戶“已經登錄過”的狀態。
比如：我在購物網站已經登錄了，攻擊者發給我一個釣魚鏈接，我一不小心點開，頁面偷偷幫我發起一個“轉賬請求”。由于瀏覽器會自動帶上我的 cookie，后端以為是我自己點的，就執行了。
而這個問題的核心就是：后端只校驗了 cookie/session，沒有校驗請求是不是用戶主動發起的。
CSRF 防御
CSRF 的問題在于“瀏覽器自動帶 cookie”，所以要讓攻擊者沒法偽造一個合法請求。
- CSRF Token：后端生成一個隨機 token，前端每次請求都帶上。攻擊者拿不到這個 token，就無法偽造請求。
- SameSite Cookie：把 cookie 設置成
SameSite=Strict或Lax，這樣第三方頁面發請求時不會帶上 cookie。 - 雙重驗證：比如轉賬這種操作，要求輸入一次密碼或驗證碼，就算點了釣魚鏈接也沒用。
- 校驗 Referer/Origin：后端檢查請求頭來源是不是自己域名。
什么是回流（Reflow）和重繪（Repaint）？它們的觸發場景是什么？
這個問題基本屬于 瀏覽器渲染原理的必考點。
給大家一段代碼，這段代碼展示了 重繪 和 回流 的場景。
<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>先說回流（Reflow）：
回流就是瀏覽器需要重新計算頁面元素的 幾何結構和布局。
比如位置、大小、盒子模型這些東西一旦變了，瀏覽器得重新排版。
常見觸發場景有：
- 改變元素的大小（width、height、padding、margin、border）。
- 改變元素的顯示狀態（比如
display: none→block）。 - DOM 結構的增刪，或者位置變化。
- 獲取一些需要最新布局信息的屬性，比如
offsetHeight、getBoundingClientRect()，這些都會強制觸發回流。
再說重繪（Repaint）：
重繪是瀏覽器已經知道元素的位置和大小沒變，但需要重新畫一遍樣式，比如顏色、背景、陰影。它不用重新計算布局，只是重新繪制像素。
常見觸發場景有：
- 改變顏色（color、background-color）。
- 改變可見性（
visibility: hidden）。 - 改變陰影（box-shadow）。
一個比較核心的面試區別點是：
- 回流一定會引起重繪，但重繪不一定回流。
- 回流開銷更大，因為它會觸發布局計算，性能影響比單純的重繪要重。
