淺談一下「代面」，避坑，毀一生...
Hello，大家好，我是 Sunday。
昨天晚上的時候有位同學聯系我，提到了一個非常非常敏感的話題，那就是 代面。
很多同學可能不太明白這個詞哈，先跟大家同步一下什么是 「代面」。
所謂代面指的是：候選人請別人冒充自己參加面試，通過線上或線下形式回答面試問題，騙取企業的錄用機會。
其實 代面 這個事情很早就有了，我記得最初在 Facebook 就爆出過大量代面的問題。
并且現在國外，依然存在大量 代面 的情況，甚至已經成為一個 “產業” 了，是不是特別可怕。
上圖中我進行了大量的打碼，大家也 不要 去聯系這種，風險特別大，毀一生...
這種東西，我覺得不用我說大家心里應該也有數吧 絕對是非常非常不靠譜的！
我們知道，目前國內的面試主要分為 線上 、線下 兩種。
線下就不用說了，真人過去，入職換人了，傻子也能看出來。
但是 線上面試，情況就復雜很多了。
線上代面的常見“套路” 主要有三種：
1. 鏡頭內外雙人配合
鏡頭前坐著候選人，假裝自己在答題。
背后真正的“高手”通過小耳機或者提示板，在實時喂答案。
2. 完全替代
直接找一個人全程頂替自己參加面試。
候選人提供身份證信息和簡歷，代面者偽裝成“本人”應答。
3. 共享屏幕協助
讓“高手”遠程控制或實時打字，候選人只負責開口重復。
這三種方式，乍一聽好像有點戲，但是實際上 問題會非常多，比如：
- 回答問題出現明顯延遲（你得等“高手”說完，然后你在說）
- 面試開視頻，會出現明顯的緊張。完全替代的方式會被發現 面試者 與 入職者 不是同一人
- 共享屏幕協助 延遲更大
所以，你還不如 實時問 AI 呢！
并且，我們需要知道的是 一旦代面被發現，那么會被終身拉黑的！！！
互聯網圈子其實很窄，HR、獵頭之間也會有交流。你一旦被發現有 代面 行為，上了一個大廠黑名單，很可能會被其他大廠同步共享。從此，真正的大廠機會可能就徹底與你無緣。
因此，哪怕只是幫同學優化簡歷，在面對大廠時，我們也絕不會出現任何虛假的情況。因為我們深知：真實、可信，才是進入大廠的唯一通道！
所以，最后我給這位同學的回復是
圖片
OK，那么說完了這個事之后，大家就得知道了哈 打鐵還得自身硬 呀。
下面，咱們就老規矩，再看兩道前端的面試題，打打鐵：
事件循環（Event Loop）是怎么工作的？
事件循環（Event Loop）可以理解成瀏覽器/Node 在調度代碼執行的“總控中心”。所有任務分成兩類：
- 宏任務（MacroTask）：像
setTimeout、setInterval、script 整體代碼、I/O、UI 交互事件回調。 - 微任務（MicroTask）：優先級更高，比如
Promise.then/catch/finally、queueMicrotask、MutationObserver。
執行順序可以這么理解：
- 先把同步代碼執行完。 整個 JS 文件會作為一個宏任務執行，所以一上來就是執行 script 里的同步代碼。
- 同步代碼跑完后，看有沒有微任務。 比如你
Promise.resolve().then(...)，這類會被放進微任務隊列。執行時，會把本輪產生的所有微任務清空，直到隊列為空。 - 清空微任務隊列后，瀏覽器才有機會渲染頁面。 （這一點很關鍵，比如你在微任務里瘋狂修改 DOM，渲染會被推遲到微任務隊列清空后。）
- 渲染完后，再去取下一個宏任務。 比如
setTimeout(fn, 0)觸發了，它的回調就會在這里執行。
然后再回到第 2 步，繼續跑微任務 → 渲染 → 取宏任務，如此循環。
舉個例子：
console.log('start')
setTimeout(() => {
console.log('timeout')
}, 0)
Promise.resolve().then(() => {
console.log('promise1')
}).then(() => {
console.log('promise2')
})
console.log('end')執行過程：
- 先跑同步：打印 start，注冊
setTimeout，打印 end。 - 同步完了，看微任務：
執行第一個 then → 打印 promise1。
又產生一個微任務（第二個 then） → 打印 promise2。
- 微任務清空完，瀏覽器渲染。
- 再去執行宏任務隊列里的
setTimeout→ 打印 timeout。
最終輸出順序：
start
end
promise1
promise2
timeout跨域有哪些解決方案？
跨域的根本原因是 瀏覽器的同源策略，它會限制前端直接去請求不同域名、端口、協議的接口。
解決方案針對不同的場景（生產環境、開發環境），可以分為好幾種，常見的有：
1. 本地開發環境的代理
開發的時候最常用的就是 devServer 代理，比如 webpack 的 devServer 或 vite 的 server.proxy。
前端請求 /api，本地代理會幫你轉發到 http://lgdsunday.club，這樣瀏覽器看到的還是同源路徑，就不會報跨域。
但是要注意：這個方案只適合本地（開發時）調試。
2. CORS
主要是通過后端處理。
后端在響應頭里加上 Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers 這些，明確告訴瀏覽器哪些源可以訪問。
好處是：前端不需要改動，直接發請求就行。開發時和生產都可以這么用
3. Nginx 反向代理
主要應對 生產時。
比如前端請求 /api/user，實際上 Nginx 會把它轉發到 http://lgdsunday.club/user。
對瀏覽器來說是同源的請求。
這個方案可以和負載均衡、動靜分離結合使用
4. 頁面之間的跨域通信
如果不是接口請求，而是兩個不同域名的頁面要傳消息，可以用 window.postMessage，通常配合 iframe 或新開窗口來做。
這屬于是：前端到前端的跨域通信。
5. JSONP（歷史方案）
早期沒有 CORS 的時候，大家會用 JSONP，利用 <script> 標簽不受同源限制的特性。
但它只能 GET 請求，而且有安全隱患，所以現在基本淘汰了。
