webpack到vite的改造之路

前言

隨著前端項目的持續迭代與功能擴展，當前基于 Webpack 構建的項目在啟動速度、構建速度和首屏加載性能方面逐漸暴露出一些瓶頸。
一方面，Webpack 的打包機制導致本地開發環境的啟動時間顯著增加，嚴重影響了開發效率；另一方面，由于項目架構設計上的局限性，組件間的通信邏輯較為復雜，缺乏統一的管理和抽象，許多特殊組件的通信邏輯直接耦合在業務代碼中，缺乏可維護性和可擴展性。
這種現狀不僅增加了新開發人員的理解成本，也提高了后期維護和迭代的風險。為了解決這些問題，提升整體開發體驗與項目可維護性，我們決定對前端項目進行一次系統性的技術升級。
本次技術升級主要圍繞多個核心目標展開：
一、構建工具的優化，由 Webpack 升級為 Vite，以大幅提升項目啟動速度和開發體驗；
二、組件通信機制進行重構，引入更合理的狀態管理與通信機制，解耦組件間的依賴關系，提升代碼的可讀性與可維護性。
三、組件渲染邏輯優化，減少不必要的渲染和資源加載, 提高渲染效率
四、靜態資源優化，減少資源體積, 增加緩存命中率等
五、組件設計優化，減少不必要的屬性監聽,減少響應式的性能消耗, 減少重復渲染問題等

建設歷程

一、構建工具由 Webpack 升級為 Vite

為了解決項目啟動速度慢、開發體驗差等問題，我們決定將前端項目的構建工具由 Webpack 升級為 Vite 。Vite 是一個基于原生 ES Modules（ESM）的現代前端構建工具，具備極快的冷啟動速度和即時熱更新能力，極大地提升了開發效率。
然而，在遷移過程中我們也遇到了一些兼容性挑戰。由于 Vite 默認僅支持 ES Modules 模塊系統，而原有項目中存在部分使用 CommonJS 模塊語法（如 require 和 module.exports）的代碼和依賴庫，這導致部分模塊無法正常運行。
1、commonjs語法兼容性問題
（1） 遇到的問題：CommonJS 中 require.context 的正則解析異常
在項目中，我們曾使用 require.context 動態引入多個文件，例如：

const context = require.context('./modules', true, /.*\.js$/);

該寫法在 Webpack 中運行良好，但在遷移到 Vite 后無法正常工作。原因是 Vite 并不原生支持 require.context，且雖然可以通過 vite-plugin-commonjs 插件來實現一定程度的兼容性支持，但該插件本身存在一個已知缺陷：當 require.context 的第三個參數（即匹配正則）中包含括號（如 (xxx)）時，插件內部使用的正則解析邏輯會提前終止，導致路徑匹配失敗。
具體表現為：

  • 正則中若出現未轉義的右括號 )，插件無法正確識別整個正則表達式；
  • 導致動態引入路徑失敗，進而引發模塊加載錯誤。
    （2）解決方案：全面采用 Vite 原生支持的 import.meta.glob 語法, 為了避免對第三方插件的依賴以及潛在的兼容性問題，我們決定不使用 vite-plugin-commonjs，而是對項目中的所有 require.context 調用進行了重構，統一替換為 Vite 原生支持的 import.meta.glob 方式。
    示例對比：
  • 舊寫法（CommonJS + require.context）
const context = require.context('./modules', true, /\.js$/);
context.keys().forEach(key => {const module = context(key);
});
  • 新寫法（Vite 支持的 import.meta.glob）
const modules = import.meta.glob('./modules/**/*.js');Object.keys(modules).forEach(async (path) => {const module = await modules[path]();
});

通過這種方式，我們不僅解決了兼容性問題，還實現了以下優勢：

  • 完全適配 Vite 的 ESM 構建機制；
  • 提升了構建性能與開發體驗；
  • 減少了對非官方插件的依賴，提高項目的穩定性與可維護性。

成果總結
本次構建工具從 Webpack 切換至 Vite 的過程中，我們成功解決了模塊系統兼容性問題，并通過重構代碼去除了對 CommonJS 的依賴。最終實現了：

  • 開發環境冷啟動時間大幅縮短；
  • 熱更新響應速度顯著提升；
  • 項目結構更符合現代前端開發規范；
  • 為后續的技術演進打下了良好的基礎。
1、環境變量兼容性問題及遷移方案

在從 Webpack 遷移到 Vite 的過程中，我們還遇到了關于環境變量使用的不兼容問題。

  1. 遇到的問題：process.env 不再可用
    原有項目中廣泛使用了 process.env 來讀取環境變量，例如：
const env = process.env.VUE_APP_ENV;
const nodeEnv = process.env.NODE_ENV;

但在 Vite 中，由于其基于瀏覽器原生 ES Modules 的機制，并不再支持 Node.js 的 process.env 方式來獲取環境變量。Vite 提供了新的方式 import.meta.env 來訪問環境變量，且默認只會識別以 VITE_ 開頭的變量。
這就導致原有的環境變量無法被正確識別和注入，造成代碼運行異常。

（1）解決方案：統一替換為 import.meta.env 并規范變量命名
為了實現平滑過渡并減少對舊寫法的依賴，我們采用了如下解決方案：
創建 .env.dev（及其他環境文件）根據 Vite 的規范，我們在項目根目錄下創建了對應的 .env 文件，如 .env.dev、.env.prod 等，用于定義不同環境下的變量：

# .env.dev
VITE_APP_ENV=development
VITE_NODE_ENV=development

（2）配置 vite.config.js 支持多前綴識別（可選）
為了兼容部分歷史命名習慣（如 NODE_ENV），我們在 vite.config.js 中通過配置 envPrefix，允許 Vite 同時識別 VITE_、NODE_ 和 VUE_ 前綴的變量：

// vite.config.js
export default defineConfig({// ...envPrefix: ['VITE_', 'NODE_', 'VUE_']
});

這樣，即使變量名為 VUE_APP_ENV 或 NODE_ENV，也可以在 import.meta.env 中被正確讀取。

（3）編寫插件自動替換 process.env.XXX 寫法（可選）
考慮到項目中存在大量使用 process.env 的代碼，為了降低重構成本，我們開發了一個輕量級的 Vite 插件，在構建階段將所有 process.env.XXX 替換為 import.meta.env.XXX，從而實現兼容性處理。
雖然最終我們選擇手動替換關鍵路徑上的環境變量引用，但該插件也為其他項目的遷移提供了可復用的解決方案。
成果總結
通過本次環境變量的遷移工作，我們實現了：

  • 所有環境變量統一通過 import.meta.env 訪問；
  • 變量命名更加規范，符合 Vite 的安全與構建機制；
  • 項目具備良好的跨環境配置能力，便于后續部署與維護；
  • 減少了對 Node.js API 的依賴，提升項目現代化程度。
2、 CSS 中引入 node_modules 樣式兼容性問題

在項目遷移至 Vite 的過程中，我們還遇到了一個關于 CSS 文件中引用第三方庫樣式路徑解析失敗的問題。

1. 遇到的問題：Vite 無法識別 ~ 路徑前綴
在原有基于 Webpack 的項目中，我們習慣使用如下方式在 CSS 文件中引入 node_modules 中的樣式文件：

@import '~normalize.css/normalize.css';

其中的 ~ 前綴是 Webpack 特有的語法，用于指示構建工具將路徑解析為 node_modules 中的模塊。然而，Vite 并不支持該語法 ，導致在 CSS 文件中通過 @import ~xxx 引入的第三方樣式無法正確解析，編譯時報錯或樣式未生效。

2. 解決方案：采用更標準或兼容的方式引入第三方樣式
為了徹底解決該問題，我們采用了以下兩種方式，根據實際使用場景靈活選擇：
（1）方式一：使用插件自動替換 ~ 路徑（可選）
我們調研并嘗試了部分社區插件（如 unplugin-vue-components 或自定義 PostCSS 插件），用于在構建階段自動將 ~ 替換為正確的模塊路徑。雖然這種方式能夠實現對舊寫法的兼容，但由于其依賴額外插件且不夠直觀，我們在最終方案中并未廣泛采用。
（2）方式二：直接在 JS 入口文件中導入樣式（推薦）
考慮到 Vite 對模塊路徑的處理機制更加清晰，我們統一將原本在 CSS 中通過 @import ‘~xxx’ 引入的第三方樣式，改為在入口文件（如 main.js）中以 import 方式直接引入：

// main.js
import 'normalize.css/normalize.css';

這種方式不僅解決了路徑解析問題，還具備以下優勢：

  • 更符合現代前端模塊化的規范；
  • 提升了樣式的加載控制能力；
  • 減少 CSS 文件對構建工具特有語法的依賴，提高可移植性。
    此外，對于其他第三方 UI 庫（如 element-ui、ant-design-vue 等）所依賴的樣式文件，我們也統一采用相同方式引入，確保整個項目的樣式加載邏輯一致性。
3、Worker 文件導入異常問題及解決

在將項目從 Webpack 遷移到 Vite 的過程中，我們遇到了一個關于 Web Worker 文件引入方式不兼容的問題。

  1. 遇到的問題：Worker 模塊導出格式解析失敗
    在原有代碼中，我們使用如下方式引入一個自定義的 Web Worker 文件：
import Worker from './cross-table.worker.js';
let worker = new Worker();

但在遷移到 Vite 后，瀏覽器控制臺報錯如下：

Uncaught SyntaxError: The requested module '/src/views/panel/components/CrossTable/cross-table.worker.js' does not provide an export named 'default' (at index.vue:120:1)

該問題是由于 Vite 對模塊化的處理機制與 Webpack 不同所致。Vite 默認以 ES Module 方式處理所有 .js 文件，而 Web Worker 文件本質上并不是標準的 ES Module，因此無法通過 import 直接引入并作為構造函數使用。

1. 解決方案：采用 Vite 支持的 Worker 加載方式
為了解決這一問題，我們根據 Vite 官方文檔推薦的方式，采用了以下兩種方案進行適配：

（1）方式一：使用 ?worker 查詢參數引入 Worker 模塊
Vite 提供了特殊的查詢語法 ?worker，用于將 Worker 文件作為模塊引入，并自動創建 Worker 實例：

import Worker from './cross-table.worker.js?worker';
let worker = new Worker();

這種方式簡潔直觀，適用于大多數 Worker 場景，并能很好地與 Vite 的模塊系統集成。

（2）方式二：使用 new URL(…, import.meta.url) 顯式構造路徑
為了進一步提升兼容性并避免對 ?worker 插件機制的依賴，我們在部分關鍵組件中采用了更底層、更可控的方式加載 Worker：

// 原寫法（Webpack 環境下可用）
let worker = new Worker();// 新寫法（適配 Vite）
let worker = new Worker(new URL('./cross-table.worker.js', import.meta.url), {type: 'module'
});

這種方式通過 import.meta.url 構造絕對路徑，確保 Worker 路徑正確無誤，同時設置 { type: ‘module’ } 表示該 Worker 使用 ES Module 語法，保證與 Vite 的構建機制兼容。
成果總結
通過本次對 Web Worker 引入方式的重構，我們成功解決了：

  • Vite 下 Worker 文件無法通過 import 正常導入的問題；
  • 模塊導出格式不匹配導致的運行時錯誤；
  • 實現了更加穩定和標準的 Worker 加載邏輯；

二、事件通訊機制的優化

1. 組件通信機制重構
在項目開發過程中，我們發現原有的組件通信邏輯存在一定的冗余性和高度耦合性，特別是在處理一些復雜交互組件（如富文本組件）時，其事件注冊和監聽機制并未很好地封裝在組件內部，而是集中放置在一個公共的事件處理文件中統一管理。
這種設計雖然在初期實現上較為簡單，但隨著功能迭代和組件數量增加，逐漸暴露出以下幾個問題：

  • 邏輯分散、難以維護 ：組件相關的事件監聽與業務邏輯分離，查找和修改變得困難；
  • 強耦合導致復用性差 ：事件處理依賴全局上下文，組件無法獨立運行或被復用；
  • 新開發者學習成本高 ：需要理解整個事件系統的運作機制，才能正確使用某個組件；
  • 可擴展性受限 ：新增功能或修改已有行為時，容易引發連鎖改動，影響其他模塊。

2. 以富文本組件為例說明重構過程
富文本組件是一個典型的具有復雜交互邏輯的組件，它支持動態參數插入（通過接口實時獲取），并能與其他組件進行聯動篩選。原有實現中，該組件的事件注冊（如數據更新、篩選觸發等）全部在全局事件中心完成，導致組件本身與外部通信機制緊密綁定。
? 重構目標：

  • 將組件相關的事件監聽和響應邏輯封裝到組件內部；
  • 實現組件間通信的解耦；
  • 提升組件的可復用性、可維護性和可讀性；
  • 減少對全局事件中心的依賴。

🔧 重構方案：
我們將富文本組件中的事件注冊和監聽邏輯從全局事件中心抽離，改由組件自身負責，并采用以下方式進行優化：

  • 使用 Vue 的 $emit 和 $on 進行父子組件之間的通信；
  • 對跨級通信需求，引入 provide/inject 或狀態管理模塊（如 Pinia/Vuex）進行統一狀態共享；
  • 在組件內部通過生命周期鉤子（如 mounted、beforeUnmount）動態注冊和銷毀事件監聽器；
  • 對于需要跨組件通信的場景，使用事件總線（EventBus）或自定義 Hook 進行封裝，降低耦合度；

成果總結
通過對富文本組件及其他關鍵組件的通信機制進行重構，我們實現了以下成果：

  • 組件內部邏輯更加清晰 ：事件注冊和響應邏輯收歸組件自身，職責單一；
  • 減少耦合，提高可維護性 ：不再依賴全局事件中心，組件可獨立運行和測試；
  • 提升可擴展性 ：后續新增功能或復制組件時，無需額外修改事件系統；
  • 降低學習成本 ：新開發者只需關注組件本身即可理解其行為邏輯。

三、組件渲染邏輯優化

隨著看板組件數量的增長（當前已達 45 個），原有項目在首次加載時存在明顯的性能瓶頸。由于未實現組件懶加載機制，所有組件都會在頁面初始化階段一次性加載并渲染，導致首屏加載時間過長，頁面出現明顯卡頓，嚴重影響用戶體驗。
此外，項目中采用了全量注冊組件的方式引入所有組件模塊，進一步加劇了資源加載壓力。
為了解決上述問題，我們從組件加載機制 和渲染策略 兩個方面進行了系統性優化。

1. 首屏加載性能問題分析
（1）組件未做懶加載，首屏渲染壓力大
原有看板組件采用同步加載方式，在頁面初始化階段即全部掛載并渲染，即使部分組件位于可視區域之外或尚未被用戶訪問，仍會參與 DOM 構建和數據請求，造成不必要的性能損耗。
（2）組件注冊采用全量引入模式，資源消耗高
通過以下方式注冊組件：

import.meta.glob(['./*/index.vue', './*/config.vue', './*/commonConfig.vue'], { eager: true });

該方式會導致 Vite 在構建時將所有組件模塊提前加載至主包中，顯著增加初始加載體積和執行時間。

優化方案實施
針對以上問題，我們從以下兩個維度進行了重構與優化：
? （1）實現組件懶加載機制 —— 按需渲染可視區域內的組件
我們采用瀏覽器原生 API IntersectionObserver 來監聽組件是否進入可視區域，僅當組件即將進入用戶視野時才觸發其加載與渲染。
實現步驟如下：

  • 將組件容器包裹在 <LazyComponent> 中；
  • 使用 IntersectionObserver 監聽目標元素是否出現在可視區域內；
  • 當滿足條件時，動態加載組件并插入 DOM；
  • 對于已加載過的組件，避免重復加載，提升復用效率；
    示例代碼如下：
<template><div ref="container" class="component-wrapper"><component v-if="isVisible" :is="loadedComponent" /></div>
</template><script>
export default {data() {return {isVisible: false,loadedComponent: null};},mounted() {const observer = new IntersectionObserver(([entry]) => {if (entry.isIntersecting) {this.isVisible = true;import(`@/components/${this.componentName}/index.vue`).then(module => {this.loadedComponent = module.default;});observer.unobserve(this.$refs.container);}}, { rootMargin: '0px 0px 200px 0px' }); // 提前預加載observer.observe(this.$refs.container);}
};
</script>

📈 成果效果：

  • 首屏組件數量大幅減少；
  • 初始渲染時間縮短 60% 以上；
  • 頁面流暢度顯著提升，避免“白屏”、“卡頓”等不良體驗。

? （2）重構組件注冊方式 —— 改為按需異步加載注冊
為了避免全量注冊帶來的資源浪費，我們將原有的同步注冊方式改為異步懶加載注冊模式，建立一個組件注冊映射池，按需加載所需組件。
實現方式如下：

// componentRegistry.js
export const ComponentMap = {'chart-bar': () => import('@/components/chart-bar/index.vue'),'table-cross': () => import('@/components/table-cross/index.vue'),// ...其他組件
};

在看板渲染器中根據配置動態加載對應組件：

<template><component :is="currentComponent" />
</template><script>
export default {props: ['componentName'],data() {return {currentComponent: null};},created() {ComponentMap[this.componentName]?.().then(comp => {this.currentComponent = comp.default;});}
};
</script>

📈 成果效果：

  • 初始加載組件數量由 45 個降至實際使用數（通常小于 10 個）；
  • 包體積顯著減小；
  • 資源利用率更高，提升整體加載效率。

? （3）添加骨架屏，提升用戶感知體驗
為了進一步優化用戶的視覺體驗，避免因組件延遲加載而造成的“空白感”，我們在看板渲染器中增加了骨架屏機制 。
具體做法包括：

  • 在組件加載前展示占位骨架圖；
  • 骨架圖樣式與真實組件保持一致，降低視覺跳躍感；
  • 加載完成后平滑過渡到真實內容；
    這不僅提升了頁面的交互友好性，也有效緩解了用戶對加載過程的焦慮感。

成果總結
通過本次組件渲染邏輯的深度優化，我們實現了以下幾個方面的顯著提升：

優化方向集體成果
組件懶加載首屏加載組件數量大幅減少，頁面響應更快
按需注冊機制組件資源不再全量加載，包體積更輕
骨架屏機制用戶體驗更流暢，避免“卡頓”假象
渲染性能整體加載速度提升 50% 以上，交互更流暢

四、靜態資源與項目打包優化

隨著項目功能的不斷完善，靜態資源和構建產物的體積逐漸成為影響首屏加載速度和用戶體驗的重要因素。為此，我們從圖片壓縮、CSS 優化、依賴拆分、Gzip 壓縮等多個維度 對項目的靜態資源和打包策略進行了系統性優化，顯著提升了整體加載性能。
1. 靜態資源壓縮 —— 圖片資源優化
項目中存在大量圖片資源（如圖標、背景圖等），未經過壓縮處理會直接影響頁面加載速度。
? 優化措施：

  • 使用自動化工具（如 imagemin、TinyPNG CLI）對 PNG/JPG/SVG 等格式進行批量壓縮；
  • 引入 WebP 格式替代傳統 PNG/JPG，在保持視覺質量的同時減少文件體積；
  • 對大圖資源采用懶加載策略，僅在進入可視區域時加載；
    📈 成果效果：
  • 圖片平均體積壓縮率達 50% 以上；
  • 頁面首次加載所需加載的圖片資源大幅減少；
  • 用戶感知加載速度明顯提升。

2. 第三方依賴分離打包 —— 按需加載 & 緩存復用
原有打包策略將所有代碼（包括業務邏輯和第三方庫）打包為一個或多個 chunk，導致初始加載包過大，影響首屏加載速度。

? 優化措施：

  • 在 vite.config.js 中配置 build.rollupOptions.output.manualChunks，將第三方依賴（如 vue, element-plus, axios, lodash 等）單獨打包成獨立 chunk；
  • 示例配置如下：
export default defineConfig({build: {rollupOptions: {output: {manualChunks: {vendor: ['vue', 'vue-router', 'pinia', 'element-plus'],utils: ['axios', 'lodash-es']}}}chunkFileNames: 'static/js/[name]-[hash].js',entryFileNames: 'static/js/[name]-[hash].js',assetFileNames: 'static/[ext]/[name]-[hash].[ext]',}
});
  • 利用瀏覽器緩存機制，對長期不變的第三方 chunk 設置較長的緩存時間（如 1 年）；
  • 減少重復打包，提高資源復用率；

📈 成果效果：

  • 主業務包體積減少 30% 以上；
  • 第三方庫可被瀏覽器緩存，后續加載更快；
  • 構建結果更清晰，便于分析與維護。

3. CSS 優化 —— 原子化 CSS + 冗余樣式清除
項目中存在較多重復定義的 CSS 類名，且部分組件間樣式耦合嚴重，造成 CSS 體積膨脹和渲染性能下降。
? 優化措施：

  • 引入原子化 CSS 工具（如 UnoCSS 或 [Tailwind CSS JIT 模式]），按需生成最簡樣式類；
  • 使用 PurgeCSS 清除未使用的 CSS 樣式；
  • 將全局樣式與組件樣式分離，使用 scoped 屬性避免樣式污染；
  • 合并重復類名，統一命名規范；

📈 成果效果：

  • CSS 文件體積減少 40% 以上；
  • 樣式加載更高效，頁面渲染性能提升；
  • 提升了樣式的可維護性和一致性。

4. Gzip 壓縮與 Nginx 配置優化
為了進一步壓縮構建輸出的 JS/CSS/HTML 資源體積，我們在構建階段和服務器端都啟用了 Gzip 壓縮機制。
? 優化措施：

  • 安裝并配置 vite-plugin-compression 插件，在構建時生成 .gz 壓縮文件；
  • 示例配置如下：
import viteCompression from 'vite-plugin-compression';plugins: [viteCompression({verbose: false,threshold: 10240,})
]
  • 配置 Nginx 支持 .gz 文件映射，并啟用 Gzip 解壓服務端響應；
  • Nginx 示例配置如下：
location ~ \.(js|css|html|json|xml|svg)$ {gzip_static on;add_header Content-Encoding gzip;add_header Vary Accept-Encoding;
}

📈 成果效果：

  • JS/CSS 文件體積壓縮率可達 70%；
  • 瀏覽器請求響應更快，頁面加載體驗更流暢；
  • 有效降低帶寬消耗，節省服務器成本。

成果總結
通過本次靜態資源與打包策略的全面優化，我們實現了以下幾個方面的顯著提升：

優化方向具體成果
圖片資源壓縮平均壓縮率達 50%，加載速度提升
依賴拆分主包體積減小，緩存利用率提升
CSS 優化樣式體積減少 40%，渲染效率更高
Gzip 壓縮JS/CSS 文件壓縮率高達 70%
用戶體驗優化引入骨架屏、字體優化，提升感知性能

五、組件設計優化

🚨 當前存在的問題

  • 對整個樣式/配置對象進行監聽 ，造成 Vue 對其所有屬性進行深度響應式處理；
  • 非必要屬性的響應式浪費性能 （如只讀字段、靜態配置）；
  • 僅在編輯態需要響應式監聽，發布后無需監聽 ，但當前邏輯未做區分；
  • 整體對象劫持導致不必要的副作用和內存消耗 ；

? 優化目標

  1. 減少非必要的響應式屬性追蹤 ；
  2. 按需啟用響應式監聽，區分“編輯態”與“運行態” ；
  3. 提升組件渲染性能，降低內存占用 ；
  4. 保持代碼可維護性和擴展性 。

方案一、手動控制 watch 監聽范圍（避免監聽整個對象）
📌 思路：
不要直接監聽整個對象，而是監聽具體字段路徑，或使用計算屬性做細粒度監聽。
📌 示例：

export default {data() {return {styleConfig: {color: '#000',fontSize: '14px'}};},watch: {// 錯誤寫法：監聽整個對象，觸發全量響應styleConfig: {handler(newVal) {console.log('整個 styleConfig 改變了');},deep: true},// 正確寫法：監聽具體字段'styleConfig.fontSize': function (newVal) {console.log('字體大小改變為:', newVal);}}
};

方案二、使用 Mixin 分離編輯態與運行態邏輯
📌 思路：
將編輯態相關邏輯封裝到一個 mixin 中，只有在編輯態時才混入該邏輯。
📌 示例：

// editModeMixin.js
export default {data() {return {editableStyle: {}};},watch: {// 編輯態專屬監聽邏輯}
};// component.vue
import editModeMixin from './editModeMixin';export default {// 只有編輯模式才進行屬性的監聽mixins: [this.isEditMode ? editModeMixin : {}],props: ['isEditMode']
};

本文來自互聯網用戶投稿，該文觀點僅代表作者本人，不代表本站立場。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。
如若轉載，請注明出處：http://www.pswp.cn/web/84482.shtml
繁體地址，請注明出處：http://hk.pswp.cn/web/84482.shtml
英文地址，請注明出處：http://en.pswp.cn/web/84482.shtml

如若內容造成侵權/違法違規/事實不符，請聯系多彩編程網進行投訴反饋email:809451989@qq.com，一經查實，立即刪除！

相關文章

【重構】如果發現提取的方法不再通用，如何重構

【重構】如果發現提取的方法不再通用，如何重構

前言 所謂重構&#xff08;refactoring&#xff09;&#xff1a; 在不改變代碼外在行為的前提下&#xff0c;對代碼做出修改&#xff0c;以改進程序的內部結構。 – Martin Fowler背景 最近在做需求&#xff0c;需要對方法加權限控制&#xff0c;發現舊方法不再適用&#xff0…
閱讀更多...
REST接口/RPC

REST接口/RPC

REST接口（RESTful API）是一種基于HTTP協議的API設計風格，遵循REST（Representational State Transfer表述性狀態轉移）架構原則，用于在不同系統之間進行數據交互。它具有簡潔、靈活、無狀態等特點，廣泛應用于Web服務和移動應用開發中。 核心概念 資源導向 將數據或服務抽…
閱讀更多...
JS入門——事件與事件綁定

JS入門——事件與事件綁定

JS入門——事件與事件綁定 一、事件的分類 二、事件的綁定方式 實現代碼&#xff1a; <!DOCTYPE html> <html><head><meta charset"utf-8"><title>JS事件綁定</title></head><body><!-- 修復后的按鈕1 -->&…
閱讀更多...
pyspark 處理字符串函數

pyspark 處理字符串函數

pyspark 要處理數據&#xff0c;沒有&#xff0c;那就偽造數據 faker 真是個好東西 from faker import Faker import pandas as pd gender ["None","Man","Woman"]fake Faker() names [(fake.first_name(),fake.last_name(),fake.date_of_bi…
閱讀更多...
五大經典語音芯片型號及應用場景

五大經典語音芯片型號及應用場景

在語音芯片領域&#xff0c;這五大語音芯片憑借豐富多樣的產品和卓越的性能&#xff0c;占據了重要地位。以下為您詳細介紹其五款經典語音芯片型號及其對應的應用場景。? WTN6170-8S? WTN6170-8S 屬于 OTP 一次性語音芯片。它采用 OTP 工藝&#xff0c;成本能夠控制在 1 元以…
閱讀更多...
機器學習管道：構建高效可靠的AI工作流

機器學習管道：構建高效可靠的AI工作流

在當今數據驅動的世界中&#xff0c;機器學習(ML)已成為推動創新和決策的核心技術。然而&#xff0c;將ML模型從實驗環境成功部署到生產環境并非易事。機器學習管道(ML Pipelines)作為一種系統化的解決方案&#xff0c;通過自動化工作流程&#xff0c;顯著提高了ML項目的可重復…
閱讀更多...
瀏覽器調試核心技術指南：從基礎到高級的完全掌握

瀏覽器調試核心技術指南：從基礎到高級的完全掌握

引言?? 在現代前端開發中，瀏覽器調試工具已成為開發者最強大的技術伙伴。根據State of JS 2023的統計數據，??92.7%的專業開發者??每天使用瀏覽器DevTools進行問題診斷和性能優化。然而，多數初級開發者僅能使用不到35%的調試功能。本文將系統解析Chrome/Firefox瀏覽器…
閱讀更多...
OpenCV 圖像翻轉

OpenCV 圖像翻轉

一、知識點 1、void flip(InputArray src, OutputArray dst, int flipCode); (1)、圍繞x軸、y軸或兩者同時翻轉圖像。 (2)、參數說明: src: 輸入圖像。 dst: 輸出圖像&#xff0c;大小與類型和src相同。 flipCode: 翻轉標志。 0表示繞x軸翻轉(上下翻轉);…
閱讀更多...
【動手學深度學習】4.2~4.3 多層感知機的實現

【動手學深度學習】4.2~4.3 多層感知機的實現

目錄 4.2. 多層感知機的從零開始實現1&#xff09;初始化模型參數2&#xff09;激活函數3&#xff09;模型4&#xff09;損失函數5&#xff09;訓練 4.3. 多層感知機的簡潔實現1&#xff09;模型2&#xff09;小結 . 4.2. 多層感知機的從零開始實現 現在讓我們實現一個多層感…
閱讀更多...
54-Oracle 23 ai DBMS_HCHECK新改變-從前的hcheck.sql

54-Oracle 23 ai DBMS_HCHECK新改變-從前的hcheck.sql

Oracle Hcheck&#xff08;Health Check&#xff09;是Oracle數據庫內置的健康監測工具&#xff0c;自動化檢查數據庫的核心問題&#xff0c;包括數據字典一致性、性能瓶頸、空間使用及安全隱患。本質是數據字典的CT掃描儀&#xff0c;其核心價值在于將“字典邏輯錯誤”這類灰色…
閱讀更多...
AI 產品的“嵌點”（Embedded Touchpoints）

AI 產品的“嵌點”（Embedded Touchpoints）

核心主題&#xff1a; AI 產品的成功不在于功能的強大與獨立&#xff0c;而在于其能否作為“嵌點”&#xff08;Embedded Touchpoints&#xff09;無縫融入用戶現有的行為流&#xff08;Flow&#xff09;&#xff0c;消除微小摩擦&#xff0c;在用戶真正需要的時機和場景中“無…
閱讀更多...
如何在WordPress中添加導航菜單？

如何在WordPress中添加導航菜單？

作為一個用了很多年 WordPress 的用戶&#xff0c;我特別清楚導航菜單有多重要。一個清晰的導航菜單能讓訪問者快速找到他們想要的信息&#xff0c;同時也能提升網站的用戶體驗。而對于WordPress用戶來說&#xff0c;學會如何添加和自定義導航菜單是構建高質量網站的第一步。今…
閱讀更多...
【pdf】Java代碼生成PDF

【pdf】Java代碼生成PDF

目錄 依賴 創建單元格 表格數據行輔助添加方法 創建表頭單元格 創建下劃線 創建帶下劃線的文字 創建PDF 依賴 <dependency><groupId>com.itextpdf</groupId><artifactId>itextpdf</artifactId><version>5.4.2</version> <…
閱讀更多...
Vite 的“心臟移植”：Rolldown

Vite 的“心臟移植”：Rolldown

1. 現狀&#xff1a;你擱這兒玩雙截棍呢&#xff1f; 現在Vite這逼樣&#xff1a;開發用esbuild&#xff0c;生產用Rollup&#xff0c;精分現場是吧&#xff1f;大型項目尼瑪啟動慢成狗&#xff0c;請求多到炸穿地心&#xff0c;生產/dev環境差異能讓你debug到原地升天&#x…
閱讀更多...
【網絡安全】文件上傳型XSS攻擊解析

【網絡安全】文件上傳型XSS攻擊解析

引言 文件上傳功能作為現代Web應用的核心交互模塊&#xff0c;其安全防護水平直接關系到系統的整體安全性。本文基于OWASP、CVE等權威研究&#xff0c;結合2024-2025年最新漏洞案例&#xff0c;系統剖析了文件上傳場景下的XSS攻擊技術演進路徑。研究揭示&#xff1a;云原生架構…
閱讀更多...
Java 集合框架底層數據結構實現深度解析

Java 集合框架底層數據結構實現深度解析

Java 集合框架&#xff08;Java Collections Framework, JCF&#xff09;是支撐高效數據處理的核心組件&#xff0c;其底層數據結構的設計直接影響性能與適用場景。本文從線性集合、集合、映射三大體系出發&#xff0c;系統解析ArrayList、LinkedList、HashMap、TreeSet等核心類…
閱讀更多...
Dify動手實戰教程(進階-知識庫：新生入學指南)

Dify動手實戰教程(進階-知識庫：新生入學指南)

目錄 進階-知識庫&#xff1a;新生入學指南 1.創建知識庫 2.創建Agent 去年agent智能體爆火&#xff0c;我自己也使用了多款智能體產品來搭建agent解決生活中的實際問題&#xff0c;如dify、coze等等。dify作為一個開源的框架得到了大量的應用&#xff0c;如一些需要隱私保護…
閱讀更多...
Vue3+TypeScript+ Element Plus 從Excel文件導入數據，無后端（點擊按鈕，選擇Excel文件，由前端解析數據）

Vue3+TypeScript+ Element Plus 從Excel文件導入數據，無后端（點擊按鈕，選擇Excel文件，由前端解析數據）

在 Vue 3 TypeScript Element Plus 中實現文件導入功能&#xff0c;可以通過以下步驟完成&#xff1a; 1. 安裝依賴 bash 復制 下載 npm install xlsx # 用于解析Excel文件 npm install types/xlsx -D # TypeScript類型聲明 2. 組件實現 vue 復制 下載 <templ…
閱讀更多...
一些torch函數用法總結

一些torch函數用法總結

1.torch.nonzero(input, *, as_tupleFalse) 作用&#xff1a;在PyTorch中用于返回輸入張量中非零元素的位置索引。 返回值&#xff1a;返回一個張量&#xff0c;每行代表一個非零元素的索引。 參數含義&#xff1a; &#xff08;1&#xff09;input:輸入的PyTorch 張量。 …
閱讀更多...
moments_object_model_3d這么理解

moments_object_model_3d這么理解

這篇文章是我對這個算子的理解，和三個輸出結果分別用在什么地方 算子本身 moments_object_model_3d( : : ObjectModel3D, MomentsToCalculate : Moments) MomentsToCalculate：對應三個可選參數，分別是 1， mean_points： 就是點云在xyz方向上坐標的平均值 2， central_m…
閱讀更多...
最新文章

Copyright @ 2022~2023