烏鶇科技前端二面

1. 你能給我介紹一下你參與的重要項目，并重點介紹一下做的內容?

通俗解釋： 挑一個你覺得最拿得出手、技術含量最高的項目，說說這個項目是干什么的（比如一個電商網站、一個后臺管理系統），你在里面具體負責了哪些技術部分（比如某個復雜頁面的開發、性能優化、某個關鍵模塊的設計）。
回答要點：
- 簡述項目： 項目名稱、做什么的、給誰用。
- 你的角色： 是核心開發者？還是負責某塊功能？
- 重點內容：
  
  挑1-2個最核心、最有技術挑戰的點
  
  詳細說。比如：
  - 你設計了一個很靈活的表單系統
  - 你解決了列表展示大量數據卡頓的問題
  - 你用 微前端 改造了老項目
  - 你用了一套嚴謹的方法確保代碼穩定上線
- 用數據和結果說話： 比如“優化后頁面加載速度提升了40%”，“表單提交錯誤率降低了XX%”。
- 思路： 用 STAR 原則（情景，任務，行動，結果）來組織語言。

2. 你是如何處理動態表單的狀態和渲染的?

通俗解釋： 頁面上的表單不是寫死的代碼，而是根據配置（比如從后臺獲取的JSON數據）動態生成的，字段可能變多或變少。問你怎么管理用戶填的內容（狀態），以及怎么高效地畫出這個表單（渲染）。
回答要點：
- 狀態管理： 你用什么存儲所有表單項的值？（常用：React useState, 表單庫如Formik, React Hook Form）如何收集、修改、提交？
- 動態渲染：
  - 怎么把JSON配置轉換成實際的表單項？（比如寫個函數遍歷配置，根據字段類型渲染不同的輸入框、下拉框等）
  - 如何組織結構？（可能需要遞歸渲染嵌套字段）
  - 用什么機制讓表單項的值變化后更新狀態？（onChange事件綁定）
- 關鍵點： 強調用了什么庫/工具(Formik非常常見) 或自己實現時的核心思路（數據驅動、組件遞歸）。

3. 你是如何解決受控組件和非受控組件的區別和優缺點的?

通俗解釋：

表單項（如輸入框）有兩種常見工作模式：
- 受控 (Controlled)： React “完全掌控” 輸入框的值。輸入框的值由React狀態提供，變化時通過事件更新狀態。
- 非受控 (Uncontrolled)： React “不直接掌控”輸入框的值。你需要的時候（比如提交時）用ref去獲取輸入框當前的值。
回答要點：
- 區別：
  - 受控：值 = value屬性（來自state），變化 = onChange事件（更新state）。真值在React中。
  - 非受控：初始值用defaultValue，需要用ref去DOM元素上讀取當前值。真值在DOM中。
- 優缺點：
  - 受控：
    - ? 優點：實時訪問/驗證值，即時反饋（如實時搜索），強制數據來源單一，與React思想更一致。
    - ?? 缺點：每個輸入變化都觸發渲染可能有性能問題（大表單要注意優化）。
  - 非受控：
    - ? 優點：性能可能更好（渲染少），簡單表單或集成非React庫時方便。
    - ?? 缺點：不能實時獲取/驗證值，需要手動處理（用ref），狀態分散（一部分在React外）。
- 如何選擇/解決：
  - 大多數表單推薦用受控組件，配合表單庫管理狀態和性能優化（如問題4）。
  - 特殊場景用非受控，例如：
    - 文件上傳 <input type="file"> (文件值不能受控)。
    - 集成第三方輸入庫。
    - 性能極度敏感且變化特別頻繁的字段（謹慎使用）。

4. 在大量的表單中，如何優化性能?

通俗解釋： 幾十上百個輸入框的表單，用戶輸入時感覺卡頓，你怎么讓它變快變流暢？
回答要點：
- 表單庫： 用成熟的表單庫！(Formik, React Hook Form等) 它們內置了很多優化。
- 狀態管理優化：
  - 組件拆分： 把大表單拆成小組件/子表單，這樣只有被修改的部分重渲染。
  - 精準更新： 確保每個表單項的狀態更新只影響它自己/最小相關部分（比如用Context API分發狀態和更新函數）。
  - React.memo： 對表單子組件使用 React.memo 包裹，避免不必要的渲染。
- 渲染優化：
  - 懶加載/分步渲染： 非當前步驟的表單部分先不渲染或隱藏（比如Tab標簽頁式表單）。
  - 虛擬化： 如果表單長得像列表（比如配置項列表），考慮在非常大量時用虛擬滾動思路（問題5）。
- 計算優化：
  - 防抖/節流 (Debounce/Throttle)： 實時驗證或計算時（比如輸入后自動保存草稿），延遲執行或限制頻率。
- 依賴優化：
  - 在 useEffect, useMemo, useCallback 中使用精確的依賴項數組，避免無意義的重計算和重渲染。

5. 你是如何處理虛擬滾動和分頁的?

通俗解釋：

需要展示幾千幾萬條數據（比如用戶列表、訂單記錄），如果一次性全渲染在頁面上，瀏覽器會卡死或極其緩慢。有兩種主要解決辦法：
- 虛擬滾動 (Virtual Scrolling)： 只渲染可視區域及其附近的一小部分數據，滾動時動態更新內容。用戶體驗像連續滾動沒有翻頁。
- 分頁 (Pagination)： 數據分成很多“頁”，只顯示當前頁的數據，用戶需要點擊頁碼切換。
回答要點：
- 虛擬滾動：
  - 原理： 監控滾動位置，計算出當前可視區域顯示的數據項應該是整個數據集的哪一段（索引范圍），只渲染這一段對應的列表項。
  - 庫： 強烈建議用現成的庫！比如 react-window 或 react-virtualized。
  - 優點： 用戶體驗流暢，無縫滾動。
  - 缺點： 復雜列表項實現起來可能稍難，需要計算高度（固定高度簡單，可變高度復雜）。
  - 適用場景： 長列表，需要連續滾動體驗，用戶可能快速滾動查找。
- 分頁：
  - 原理： 后端按頁碼或游標請求數據，前端只顯示當前頁的數據。需要提供頁碼控件（上一頁/下一頁/跳轉）。
  - 實現： 相對簡單，后端查詢加前端組件（或用Table自帶的分頁）。
  - 優點： 實現簡單，內存占用小。
  - 缺點： 頻繁翻頁體驗不夠流暢。
  - 優化： 結合預加載 (Prefetching) - 比如預加載下一頁數據；無限滾動分頁 (滾動到底部自動加載下一頁)，體驗接近虛擬滾動但實現相對簡單。
- 如何選擇：
  - 絕大多數后臺管理系統用分頁就夠了，簡單高效。
  - 對用戶體驗要求高、列表超長（如社交動態、商品瀑布流）首選虛擬滾動。
  - 也可以結合：虛擬滾動處理單頁內容，分頁處理請求不同批次數據。

6. 你是如何解決微前端的狀態隔離和樣式污染的問題的?

通俗解釋：

微前端就是把大網站拆成多個獨立的小應用（子應用）拼起來（基座應用）。不同小應用之間互相影響怎么辦？
- 狀態隔離： App A 的變量/狀態會不會意外修改了 App B 的？
- 樣式污染： App A 寫的全局CSS會不會影響了 App B 的外觀？
回答要點：
- JS 沙箱/狀態隔離：
  - 核心思路： 讓每個子應用在獨立的環境里運行。
  - 常用方案：
    - 庫自帶方案： 像 qiankun 內置了 JS 沙箱（常用 Proxy 攔截全局對象操作）。
    - iframe： 天然隔離，但太重、通信不便（postMessage），通常不是首選。
    - 命名空間/約定： 約定全局變量/事件使用特定前綴 (如 AppA_eventName)，容易出問題，不夠安全。
- CSS 樣式污染：
  - 核心思路： 限制子應用樣式的生效范圍。
  - 常用方案：
    - Shadow DOM： 最徹底隔離！子應用的樣式被封閉在#shadow-root里，完全不影響外部。但部分CSS選擇器在里面會失效，子應用適配需要成本。
    - CSS Scoping： 給子應用根元素加特殊ID或data-屬性，子應用的所有CSS規則前都加這個選擇器。通常借助打包工具（如 postcss 插件）自動添加。
    - CSS Modules / CSS-in-JS： 在構建時把類名變成唯一的（如.header__2Fd5s），天然避免沖突。強烈推薦在子應用中廣泛使用！
    - 約定前綴： 所有類名、ID、動畫名都加上子應用專屬前綴 (如 microapp-a-button)，但依賴人工管理，容易遺漏。
- 通信：
  
  隔離后需要通信怎么辦？（通常是
  
  父->子
  
  傳數據，
  
  子->父
  
  發事件）。
  - 利用框架能力：如 single-spa 提供生命周期的數據傳遞。
  - 自定義事件 (CustomEvent)：基座和子應用通過window監聽和派發事件。
  - 狀態管理庫：像Redux或Mobx，如果共享Store需要設計命名空間或模塊隔離。
  - 重點： 通信設計需要簡單清晰，避免濫用，保持低耦合。

7. 你是如何使用useEffect的?

通俗解釋： useEffect 是React Hooks中最常用（但也容易用錯）的Hook之一，用來處理副作用操作（比如調API、操作DOM、設置定時器、事件監聽等）。問你平時怎么正確有效地用它。
回答要點：
- 理解依賴數組： 它是useEffect的心臟。里面的變量變了，里面的函數（副作用）就重新運行。
- 關鍵原則：
  - 包含所有依賴： 副作用函數內部用到的外部變量（來自prop或state），都應該加到依賴數組里（除非確定不需要響應變化）。Eslint規則 (eslint-plugin-react-hooks) 會幫忙檢查。
  - 清理工作： 在返回的函數里做清理（如移除事件監聽、取消定時器、取消請求）。
  - 避免無限循環： 依賴變化->執行副作用->副作用更新了依賴->導致再次執行… 避免在副作用里修改依賴項。
- 常見用途：
  - 數據獲取 (fetch/axios)： 注意：直接在 useEffect 里寫 fetch 不能加 async（副作用函數不能是async函數）。解決方法：在里面定義一個async函數并調用它。
  - 手動操作DOM (如 focus, 集成圖表庫)：
  - 事件監聽 (window.addEventListener)： 清理階段務必 removeEventListener。
  - 定時器 (setTimeout/setInterval)： 清理階段務必 clearTimeout/clearInterval。
- 性能考慮：
  - 避免在副作用里做很耗時的同步操作（會阻塞渲染）。
  - 依賴項是復雜對象時，考慮使用useMemo包裹對象，避免依賴頻繁變化觸發無意義副作用執行。
  - 依賴數組為 []，表示只在組件掛載后運行一次（常用于初始化請求、添加事件監聽）。

8. 你是如何解決前端項目的發布部署和上線流程的?

通俗解釋： 你開發完代碼后，怎么把它弄到服務器上讓大家訪問？這個過程是怎么自動化、保證安全的？
回答要點：
- CI/CD (持續集成/持續部署)： 核心是自動化流水線。常用工具：Jenkins, GitLab CI/CD, GitHub Actions, Travis CI。
- 流程步驟：
  1. 代碼提交: 推送代碼到Git倉庫。
  2. 自動化測試 (CI)：
    - 代碼規范檢查 (ESLint, Stylelint)。
    - 單元測試 (Jest, Mocha)。
    - 集成/E2E測試 (Cypress, Playwright)。
    - 重點： 任何一步失敗，就中止部署并通知開發者。
  3. 代碼構建： 運行 npm run build 或 yarn build，生成生產環境的優化代碼 (build 或 dist 文件夾)。
  4. 部署 (CD)：
    - 把構建好的代碼包上傳到服務器或云存儲 (如 AWS S3, 阿里云OSS)。
    - 更新服務的入口配置（比如Nginx配置）。
  5. 驗證： 自動化或手動檢查線上功能是否正常。
- 關鍵環節/策略：
  - 分支策略： master/main 主干分支代表生產環境代碼；develop 開發分支；feature/xxx 功能分支。PR/MR合并代碼。
  - 灰度發布/金絲雀發布： 新版本先推給一小部分用戶（如內部用戶，特定比例用戶），驗證沒問題再全量。
  - 回滾機制： 一旦發現問題，能快速切換到上一個穩定版本（Nginx切換指向、部署腳本支持）。
  - 版本控制： 打包文件加版本號或時間戳，方便溯源和緩存管理。
  - 環境隔離： 開發、測試、預發布、生產等環境相互隔離。
- 監控： 上線后用 Sentry 等工具監控線上錯誤，用性能分析工具監控性能指標（如 Lighthouse Score）。

9. 你是如何學習和了解新知識的，包括解決問題的方法?

通俗解釋： 技術日新月異，怎么保持自己不掉隊？遇到技術難題卡住了，你怎么一步步搞定它？
回答要點：

展示學習的主動性、系統性和解決問題的方法論。
- 學習新知識：
  - 關注渠道： 官方文檔、高質量技術博客/公眾號(掘金、InfoQ)、社區(Twitter技術大牛, Reddit /r/reactjs)、極客時間等付費課程、優秀開源項目源碼。
  - 持續投入： 每周/每月固定時間學習（如參加技術分享會、閱讀幾篇深度文章）。
  - 實踐驅動： 學完嘗試用新技術做小項目（比如學習Tauri做個桌面小工具）。
  - 追蹤趨勢： 關注年度技術報告（如State of JS）了解流行度。
  - 建立體系： 用腦圖/XMind整理知識體系，寫博客/筆記輸出（教是最好的學）。
- 解決問題的方法：
  1. 精準定位問題： 復現Bug，看錯誤信息，讀日志，弄清楚到底哪里出錯了？在什么情況下出錯？是否必現？
  2. 縮小范圍： 做一個最小的、能復現問題的例子（Minimal Reproducible Example）。
  3. 獨立思考： 先自己嘗試解決（檢查代碼邏輯、看文檔查API、斷點調試）。
  4. 善用搜索： Google錯誤信息 (用英文搜索命中率更高！)、查StackOverflow、查官方文檔、查相關庫的Issues。
  5. 請教他人： 團隊內部討論、向社區提問（描述清晰：環境、步驟、預期結果、實際結果、最小復現代碼）。
  6. 總結復盤： 問題解決后，記錄解決方案到筆記，思考如何避免類似問題（寫測試？加規范？）。

10. 你的 Career 目標和職業計劃?

通俗解釋： 未來3-5年，你想在技術/職業發展上達到什么水平？打算怎么實現？主要考察你的穩定性、上進心和與公司的契合度。
回答要點：
- 目標要具體可行： 避免空泛的“提升技術”、“成為專家”。
- 短期 (1-2年)：
  - 精通團隊使用的核心技術棧（如 React + TypeScript + Node.js）。
  - 成為團隊在特定領域（如性能優化、前端架構）的骨干。
  - 提升解決復雜問題的能力和推動項目落地的能力。
- 中期 (2-3年)：
  - 擴大技術廣度或深度：比如深入前端工程化（構建、部署、監控）、學習后端（Node/Go/Python）具備全棧能力、接觸分布式或云原生、學習團隊管理等。
  - 開始承擔更多設計和技術決策責任，能帶新人或小團隊。
- 長期 (3-5年)：
  - 成為某個技術領域的專家（Architect），或有能力負責更大范圍的技術規劃和團隊管理（Tech Lead）。
  - （可選）如果有管理傾向：希望能向技術管理方向發展。
- 計劃如何做：
  - 主動承擔有挑戰性的項目。
  - 持續學習，定期學習新知識。
  - 向團隊牛人請教。
  - 樂于分享和幫助他人。
- 結合公司： 表達希望在當前平臺上長期發展，實現目標（顯示出穩定意愿）。
- 誠懇真實： 不要說假大空的目標。