如何設(shè)計實現(xiàn)一個準確的前端倒計時

這個問題的核心是：單純用 setInterval 倒計時是不準時不可靠的。setInterval(fn, 1000) 并不保證每 1000ms 準時執(zhí)行一次。

JS 是單線程的，當(dāng)遇到大量計算、頁面渲染、長任務(wù)等，setInterval 會被延遲執(zhí)行。頁面切到后臺，定時器會被瀏覽器降頻。本該 1 秒減一次，結(jié)果 1.2 秒甚至 2 秒才執(zhí)行一次 → 倒計時變慢。

設(shè)計要點：

• 計時要以時間戳為基準（使用 Date.now 計時），而不是遞減秒數(shù)
• setInterval 只作為刷新工具。

代碼示例

const endTime = Date.now() + 60 * 1000; // 1分鐘倒計時

const timer = setInterval(() => {
  const now = Date.now();
  const remain = endTime - now;

  if (remain <= 0) {
    clearInterval(timer);
    console.log("倒計時結(jié)束");
    return;
  }

  console.log(Math.floor(remain / 1000) + "秒");
}, 1000);

總之，一個準確的前端倒計時應(yīng)該以時間戳差值為核心，而不是依賴 setInterval 的次數(shù)；定時器只負責(zé)刷新 UI，每次通過 目標時間 - 當(dāng)前時間 重新計算剩余時間，才能保證在卡頓、切后臺等場景下依然準確。

如何設(shè)計實現(xiàn)一個精準的支付秒殺倒計時

這個問題的核心是：前端倒計時必須和服務(wù)器時間一致，不能靠本地時間瞎算。

設(shè)計要點

• 以服務(wù)器時間為準。禁止用 new Date() 直接作為倒計時依據(jù)（用戶電腦時間不準）。必須先獲取一次服務(wù)端當(dāng)前時間。
• 只計算時間差，不依賴本地絕對時間。計算公式 剩余時間 = 活動開始時間 - 服務(wù)器時間
• 防止前端篡改計時，即真正是否可支付由后端控制，前端倒計時只是展示。篡改了也支付不了。

代碼示例

const diff = serverTime - Date.now();

setInterval(() => {
  const remain = startTime - (Date.now() + diff);
  updateUI(remain);
}, 1000);

一個 Web 管理系統(tǒng)，使用越來越慢，如何排查

這個問題的核心是：慢在哪里，要先定位瓶頸，再針對性優(yōu)化。一般分網(wǎng)絡(luò)、前端、后端三個方向進行定位。

先定位問題，用 Chrome DevTools：

• Network：看接口是否變慢（TTFB、響應(yīng)時間）
• Performance：看是否卡在 JS 執(zhí)行或渲染
• Memory：是否有內(nèi)存泄漏（頁面越用越卡）

前端常見的問題有

• 頁面組件越來越多，重復(fù)渲染 / 狀態(tài)管理混亂
• 大列表一次性渲染（上千條數(shù)據(jù)）
• 事件監(jiān)聽未釋放，導(dǎo)致內(nèi)存泄漏
• 打包體積變大，首屏加載慢

對應(yīng)的解決方案有：

• 虛擬列表（只渲染可視區(qū)域）
• 減少不必要的 re-render（memo、拆組件）
• 檢查未銷毀的定時器、監(jiān)聽器
• 按需加載（懶加載模塊）

接口慢常見的問題有

• 接口響應(yīng)時間變長
• 一次請求返回數(shù)據(jù)過多
• 串行請求過多

對應(yīng)的解決方案有

• 分頁 / 按需加載數(shù)據(jù)
• 合并接口 or 并行請求
• 開啟 gzip / CDN / 緩存

后端接口返回幾萬條數(shù)據(jù) 前端表格如何去展示處理

這個問題考察的是：大數(shù)據(jù)量渲染性能 + 用戶體驗 + 架構(gòu)設(shè)計能力。

設(shè)計的關(guān)鍵點是

• 不一次性渲染幾萬條數(shù)據(jù)（會卡死瀏覽器）
• 分批加載 + 按需渲染
• 保證滾動和操作流暢

解決方案有

• 后端分頁返回（如果可以的話，但面試時一般規(guī)定后端一次性返回）
• 前端使用虛擬表格，每次只渲染幾十個 DOM
• 如有數(shù)據(jù)處理，使用 web worker 解決，防止阻塞主線程
• 減少 DOM 嵌套和復(fù)雜度

H5 瀑布流展示商品信息，低端安卓機和網(wǎng)絡(luò)不穩(wěn)定，如何優(yōu)化？

針對低端安卓和弱網(wǎng)用戶，可以從 圖片壓縮 + 懶加載 + 虛擬列表 + 降級策略 + 容錯體驗 入手，減少資源體積、降低渲染壓力，保證頁面能“快加載、不白屏、可用性優(yōu)先”。

圖片資源優(yōu)化（關(guān)鍵）

• 使用 WebP / AVIF，多尺寸圖片（srcset），低端機優(yōu)先加載小圖
• 首屏用 低清圖占位（LQIP / blur） ，滾動再加載高清圖
• 圖片壓縮 + CDN
• 避免一次性加載大量圖片

網(wǎng)絡(luò)加載優(yōu)化

• 懶加載（IntersectionObserver） ，只加載可視區(qū)域圖片
• 分批請求（分頁 / 分段加載），不要一次拉全量數(shù)據(jù)
• 請求失敗自動重試 + 超時兜底
• 弱網(wǎng)模式：降低圖片質(zhì)量或數(shù)量

網(wǎng)頁渲染優(yōu)化

• 使用 虛擬列表 / 虛擬瀑布流，只渲染屏幕內(nèi)的 DOM
• 避免頻繁重排重繪（少用復(fù)雜陰影、動畫）
• 使用 transform、opacity 做動畫，避免 top/left

交互體驗優(yōu)化

• 骨架屏 / loading 占位，避免白屏
• 圖片加載失敗顯示默認圖
• 滾動時不阻塞主線程（避免大 JS 計算）

容錯和降級方案

• 低端機或弱網(wǎng)：自動切換 簡化模式（少圖 / 小圖 / 低清圖）
• 關(guān)閉復(fù)雜動畫、特效
• 監(jiān)控卡頓和加載失敗（埋點）

設(shè)計一個“單選框組件”，選項里面可能是圖片、文字等，該如何設(shè)計。

如果只包含圖片、文本這兩個，是比較好設(shè)計的，做 if-else 判斷顯示即可。但如果有其他自定義類型，就需要用到 <slot>

<template>
  <RadioGroup v-model="value">
    <!-- 文本選項 -->
    <RadioItem value="text">
      <span>文本選項</span>
    </RadioItem>

    <!-- 圖片選項 -->
    <RadioItem value="image">
      <img src="https://via.placeholder.com/80" />
      <p>圖片選項</p>
    </RadioItem>

    <!-- 自定義 slot（復(fù)雜內(nèi)容） -->
    <RadioItem value="custom">
      <div>
        <h3>自定義內(nèi)容</h3>
        <p>可以放任意組件</p>
        <button>按鈕</button>
      </div>
    </RadioItem>
  </RadioGroup>
</template>

定義兩個組件 RadioGroup 和 RadioItem ，RadioGroup 管理選中的數(shù)據(jù)

<template>
  <div class="radio-group">
    <slot />
  </div>
</template>

<script setup>
import { provide } from "vue";

const props = defineProps({
  modelValue: [String, Number]
});
const emit = defineEmits(["update:modelValue"]);

provide("radioValue", props);
provide("radioChange", (val) => {
  emit("update:modelValue", val);
});
</script>

RadioItem 負責(zé)各類數(shù)據(jù)的 UI 渲染，監(jiān)聽 change 事件來修改 value

<template>
  <div
    class="radio-item"
    :class="{ active: isChecked }"
    role="radio"
    :aria-checked="isChecked"
    @click="select"
  >
    <slot />
  </div>
</template>

<script setup>
import { inject, computed } from "vue";

const props = defineProps({
  value: [String, Number]
});

const radioValue = inject("radioValue");
const radioChange = inject("radioChange");

const isChecked = computed(() => radioValue.modelValue === props.value);

const select = () => {
  radioChange(props.value);
};
</script>

把單選框設(shè)計成 RadioGroup + RadioItem 的組合組件，用數(shù)據(jù)驅(qū)動選項，通過 slot 支持圖片和文字等自定義內(nèi)容，使用受控模式管理選中狀態(tài)，并兼顧可訪問性和性能。

如何排查網(wǎng)頁白屏問題

白屏問題本質(zhì)：頁面沒渲染出來或 JS 報錯中斷了渲染。排查要有順序，從外到內(nèi)、從簡單到復(fù)雜。

先快速定位問題方向

• 看有沒有 JS 報錯（語法錯誤、接口報錯、資源 404）。
• 看 HTML、JS、CSS 文件是否加載成功？核心接口是否返回 500 / 超時？
• 看 DOM 是否渲染出來？還是 body 是空的？

如果是 JS 報錯了，就需要

• try/catch 關(guān)鍵邏輯
• 接入全局錯誤監(jiān)控（window.onerror、unhandledrejection）

如果是 HTML、JS、CSS 文件加載失敗，就檢查 CDN 是否配置錯誤？這一般不會是程序問題。

如果核心接口返回 500 / 超時，那就在前端做容錯方案，例如展示“獲取數(shù)據(jù)失敗，請刷新重試”

還可以加 ErrorBoundary 容錯組件，來最大范圍的概括各類組件渲染報錯，給用戶提示友好信息。

總之，先看控制臺和網(wǎng)絡(luò)請求，確認是 JS 報錯、資源加載失敗還是接口問題；再定位到具體代碼。工程上通過錯誤監(jiān)控、兜底 UI 和自動化監(jiān)控來預(yù)防和快速發(fā)現(xiàn)白屏問題。

讓你啟動一個新項目，你將如何開始這個項目？

第一，要明確需求，先和產(chǎn)品、設(shè)計、后端對齊，搞清楚幾個核心問題：

• 做什么：后臺管理系統(tǒng)、C端頁面、還是小程序？
• 面向誰：用戶量多大、對性能/SEO 有沒有要求？
• 工期多久：趕進度就用成熟方案，不搞花活

第二，技術(shù)選型，要按公司團隊情況選擇，不要盲目求新

• 語言 JS TS
• 框架 Vue React Nextjs 等
• UI 組件庫 AntD Element 等
• 構(gòu)建工具 Vite

第三，工程化搭建，環(huán)境搭好，后續(xù)才能高效協(xié)作

• 代碼規(guī)范 ESLint + Prettier，保證風(fēng)格統(tǒng)一
• 配置 CI/CD 流程（GitHub Actions / Jenkins）。
• 配置環(huán)境變量、打包優(yōu)化（Tree Shaking、Code Splitting）和性能監(jiān)控（Lighthouse / Sentry）。

第四，架構(gòu)設(shè)計

• 代碼目錄結(jié)構(gòu)
• Vuex Redux 等前端狀態(tài)數(shù)據(jù)結(jié)構(gòu)
• API 接口規(guī)范
• 請求封裝：Axios 統(tǒng)一封裝，處理 token、錯誤碼、loading
• 權(quán)限控制：路由守衛(wèi) + 按鈕級權(quán)限指令提前想好

src/
├── api/        # 所有接口，按模塊拆分
├── components/ # 通用組件（Button、Modal...）
├── views/      # 頁面級組件
├── hooks/      # 復(fù)用邏輯（useUser、useTable...）
├── stores/     # 狀態(tài)管理（Pinia / Zustand）
├── router/     # 路由配置 + 權(quán)限守衛(wèi)
└── utils/      # 工具函數(shù)

如何實現(xiàn)前端線上監(jiān)控 前端線上報錯如何排查

三個主要步驟：采集、上報、分析

采集什么？

• JS錯誤：window.onerror、try-catch捕獲
• 資源加載失?。?code>window.addEventListener('error')監(jiān)聽資源
• 接口請求：重寫XMLHttpRequest和fetch
• 性能數(shù)據(jù)：Performance API獲取FP、FCP、LCP等
• 用戶行為：點擊路徑、路由變化

怎么上報？

• 封裝成固定數(shù)據(jù)結(jié)構(gòu)（錯誤信息、環(huán)境、用戶、時間戳）
• 使用Navigator.sendBeacon（頁面關(guān)閉時也能發(fā)）
• 圖片打點（new Image().src）做簡單上報
• 批量壓縮上報，減少請求次數(shù)

數(shù)據(jù)存儲和分析

• 后端可用 ElasticSearch/Kafka/數(shù)據(jù)庫 保存日志
• 提供 錯誤聚合、告警、統(tǒng)計報表，快速定位問題

前端問題如何排查

• 前端報錯日志分類、聚合，找出發(fā)生概率比較大的
• 使用 source map 將壓縮代碼映射回原始源代碼
• 根據(jù)堆棧和出錯代碼判斷邏輯或環(huán)境問題
• 在本地開發(fā)環(huán)境復(fù)現(xiàn)問題，并修復(fù)問題

一百萬個人同時搶一個商品，如何判斷誰是第一個？

這個問題的關(guān)鍵不在于前端，而在于后端，前端只是發(fā)起請求和展示結(jié)果。所以這個問題一般會考察全棧崗位或者高級前端崗位，需要有一定后段能力的。

后端實現(xiàn)這個功能，需要滿足兩點：

• 支持高并發(fā)，因為有一百萬人同時搶購
• 要能準確識別第一個人，響應(yīng)要快

常見的解決方案是 后端原子操作 ，這個方案最簡單可靠，容易支持高并發(fā)

• 所有請求打到后端
• 用 Redis / 數(shù)據(jù)庫做原子判斷

SETNX product_lock userId

第一個寫入的 user 就是贏家，其他人直接返回失敗。前端只負責(zé)發(fā)起請求和展示結(jié)果。

總結(jié)

到此這篇關(guān)于前端面試常見的10個場景題及答案的文章就介紹到這了,更多相關(guān)前端面試場景題內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論