Hello，大家好，我是 Sunday。

這段時間，經(jīng)常能在秋招群看到有人發(fā)：“要內(nèi)推嗎？這是我的碼，直接填就行。”

乍一看，好像是捷徑。填上就能繞過網(wǎng)申，HR更快看到簡歷，簡直不要太香。

但真相是：隨便亂填【陌生人】的內(nèi)推碼，坑會比你想的多。。。

想要知道原因，咱們得先想清楚 你為什么想要內(nèi)推碼？

內(nèi)推碼到底有啥用？

招聘，說白了就是一場 人才篩選的過程。

同一個崗位，幾千份簡歷同時涌進(jìn)來，HR 每天就幾個小時能看，你的簡歷很可能直接淹沒在系統(tǒng)里。

這時候，內(nèi)推碼能起的作用就是：讓你的簡歷不至于那么快沉下去。在某些公司里，帶內(nèi)推的候選人會被標(biāo)個“推薦”標(biāo)簽（注意，這只是某些廠而異），HR 篩簡歷時 可能會 優(yōu)先看。

而且，如果內(nèi)推人和你熟，他還能幫你盯一下進(jìn)度：

• 簡歷到底過沒過初篩？
• 卡在了哪一關(guān)？
• 有沒有機(jī)會補(bǔ)材料或者轉(zhuǎn)崗？

所以說，內(nèi)推碼肯定是有價值的。但是，它的價值僅局限在 讓你可以知道你當(dāng)前的進(jìn)度到底到哪了，同時有一點可能增加你的簡歷被看到的概率。

至于網(wǎng)上傳說的：“有了內(nèi)推碼，你入職的概率就會大大增加。” 這是 純扯淡 的！

為什么【陌生人】的內(nèi)推碼坑很多？

明白了內(nèi)推碼的作用，那么為什么【陌生人】的內(nèi)推碼沒用呢？

問題就出在【陌生】上。內(nèi)推的價值不是那個“碼”，而是推薦人愿不愿意為你背書，為你跟蹤進(jìn)度。

陌生人不會幫你查流程，更不會替你和HR溝通。

并且，很多公司的內(nèi)推系統(tǒng)里常常會有選項：“推薦人是否認(rèn)識候選人？”

陌生人只能選“不認(rèn)識”，這反而讓你在HR眼里是 低優(yōu)先級。

更現(xiàn)實一點，有些人發(fā)碼只是為了薅積分、沖KPI，你對他來說只是一個“數(shù)字”，投完就完事了。

并且，還有一個 大坑 就是：校招大部分都會有“投遞限制”。既：投遞的崗位數(shù)量 、次數(shù) 是有限的。

如果你是用了陌生人的內(nèi)推碼，那么假如：

你一開始投遞了 軟開崗，后來發(fā)現(xiàn)自己更適合前端崗。想改投的時候，卻發(fā)現(xiàn)投遞額度已經(jīng)用完了。

如果想要改投遞崗位，你發(fā)現(xiàn)連 內(nèi)推人 是誰你都不知道，簡歷就只能長時間泡池子了。

所以，使用【陌生人】的內(nèi)推碼，你以為自己走了捷徑。其實很有可能只是白白消耗了一次投遞機(jī)會。意義并不大。

什么時候用內(nèi)推碼才真正有用？

說到底，內(nèi)推不是靠一個“碼”，而是靠“人”。

靠譜的內(nèi)推，能讓你的簡歷真正“被看見”，還能幫你爭取額外機(jī)會。那什么時候填內(nèi)推碼才值得呢？

• 熟悉的直系學(xué)長學(xué)姐：他們最懂校招的節(jié)奏，也更愿意幫忙跟進(jìn)。比如，你卡在筆試環(huán)節(jié)，學(xué)長可能直接幫你打聽到是“代碼風(fēng)格問題”還是“題目沒過線”，這比你自己瞎猜靠譜多了。
• 朋友或同事介紹：哪怕不是同專業(yè)，只要對方真認(rèn)識你，愿意說一句“這人靠譜”，HR對你的印象分都會不一樣。
• 校園大使/校招宣講會：很多公司會指定校園大使，他們手里的內(nèi)推渠道就是官方的，并且你也可以聯(lián)系到他。
• 確認(rèn)過身份的在職員工比如通過?？?、LinkedIn 找到認(rèn)證的企業(yè)員工，能確定對方是真在崗、愿意幫忙，這種內(nèi)推才是正經(jīng)能走通的。

簡單說：內(nèi)推碼有用的前提，是推薦人愿意為你背書，而不是單純“給你個碼”。

那么最后，老規(guī)矩，咱們來看兩道前端大廠面試常見的面試問題：

XSS、CSRF 攻擊的原理是什么？

先說 XSS（跨站腳本攻擊）：

簡單理解，就是攻擊者往頁面里塞了惡意的 JS 腳本，然后讓這段腳本在用戶的瀏覽器里跑起來。

常見的做法比如在評論區(qū)插入一段 <script>alert('你被黑了')</script>，如果后臺沒做過濾，別人一打開這條評論，這個腳本就執(zhí)行了。

XSS 防御

XSS 的本質(zhì)是“用戶輸入能當(dāng)腳本跑了”，所以關(guān)鍵就是輸入要過濾，輸出要轉(zhuǎn)義。

• 輸出轉(zhuǎn)義：比如后端模板渲染時把 < 轉(zhuǎn)成 <，這樣就不會被當(dāng)成標(biāo)簽執(zhí)行。
• 輸入校驗：比如評論區(qū)只能輸入文字，不允許直接帶 <script>。
• CSP（內(nèi)容安全策略）：通過響應(yīng)頭 Content-Security-Policy 限制哪些腳本能跑，盡量只允許本域腳本。
• HttpOnly Cookie：就算頁面有 XSS，腳本也拿不到 cookie。

再說 CSRF（跨站請求偽造）：

它利用的是用戶“已經(jīng)登錄過”的狀態(tài)。

比如：我在購物網(wǎng)站已經(jīng)登錄了，攻擊者發(fā)給我一個釣魚鏈接，我一不小心點開，頁面偷偷幫我發(fā)起一個“轉(zhuǎn)賬請求”。由于瀏覽器會自動帶上我的 cookie，后端以為是我自己點的，就執(zhí)行了。

而這個問題的核心就是：后端只校驗了 cookie/session，沒有校驗請求是不是用戶主動發(fā)起的。

CSRF 防御

CSRF 的問題在于“瀏覽器自動帶 cookie”，所以要讓攻擊者沒法偽造一個合法請求。

• CSRF Token：后端生成一個隨機(jī) token，前端每次請求都帶上。攻擊者拿不到這個 token，就無法偽造請求。
• SameSite Cookie：把 cookie 設(shè)置成 SameSite=Strict 或 Lax，這樣第三方頁面發(fā)請求時不會帶上 cookie。
• 雙重驗證：比如轉(zhuǎn)賬這種操作，要求輸入一次密碼或驗證碼，就算點了釣魚鏈接也沒用。
• 校驗 Referer/Origin：后端檢查請求頭來源是不是自己域名。

什么是回流（Reflow）和重繪（Repaint）？它們的觸發(fā)場景是什么？

這個問題基本屬于 瀏覽器渲染原理的必考點。

給大家一段代碼，這段代碼展示了 重繪 和 回流 的場景。

<div id="box"></div>

<style>
  #box {
    width: 100px;
    height: 100px;
    background-color: red;
  }
</style>

<script>
  const box = document.getElementById('box');

  // 改寬度：會觸發(fā)回流 + 重繪
  setTimeout(() => {
    box.style.width = "200px";
  }, 1000);

  // 改顏色：只觸發(fā)重繪
  setTimeout(() => {
    box.style.backgroundColor = "blue";
  }, 2000);
</script>

先說回流（Reflow）：

回流就是瀏覽器需要重新計算頁面元素的 幾何結(jié)構(gòu)和布局。

比如位置、大小、盒子模型這些東西一旦變了，瀏覽器得重新排版。

常見觸發(fā)場景有：

• 改變元素的大?。╳idth、height、padding、margin、border）。
• 改變元素的顯示狀態(tài)（比如 display: none → block）。
• DOM 結(jié)構(gòu)的增刪，或者位置變化。
• 獲取一些需要最新布局信息的屬性，比如 offsetHeight、getBoundingClientRect()，這些都會強(qiáng)制觸發(fā)回流。

再說重繪（Repaint）：

重繪是瀏覽器已經(jīng)知道元素的位置和大小沒變，但需要重新畫一遍樣式，比如顏色、背景、陰影。它不用重新計算布局，只是重新繪制像素。

常見觸發(fā)場景有：

• 改變顏色（color、background-color）。
• 改變可見性（visibility: hidden）。
• 改變陰影（box-shadow）。

一個比較核心的面試區(qū)別點是：

• 回流一定會引起重繪，但重繪不一定回流。
• 回流開銷更大，因為它會觸發(fā)布局計算，性能影響比單純的重繪要重。