手把手教你構建一個web前端項目，全網最詳細教程！

1. 選擇現成的項目模板還是自己搭建項目骨架

搭建一個前端項目的方式有兩種：選擇現成的項目模板、自己搭建項目骨架。

選擇一個現成項目模板是搭建一個項目最快的方式，模板已經把基本的骨架都搭建好了，你只需要向裏面填充具體的業務代碼，就可以通過內置的工具與命令構建代碼、部署到服務器等。

一般來說，一個現成的項目模板會預定義一定的目錄結構、書寫方式，在編寫項目代碼時需要遵循相應的規範；也會內置必要的工具，比如 .editorconfig、eslint、stylelint、prettier、husky、lint-staged 等；也會內置必要的命令（package.json | scripts），比如 本地開發：npm run dev、本地預覽：npm run start、構建：npm run build、部署：npm run deploy 等。

github上比較好的項目模板：

這些模板的使用又分爲兩種：使用 git 直接克隆到本地、使用命令行創建。

（使用現有模板構建的項目，可以跳過第 2 ～ 7 步）

1.1 使用 `git` 直接克隆到本地

這是一種真正意義上的模板，可以直接到模板項目的 github 主頁，就能看到整個骨架，比如 react-boilerplate、ant-design-pro、vue-element-admin、react-starter-kit。

以 react-boilerplate 爲例：

克隆到本地：

git clone --depth=1 https://github.com/react-boilerplate/react-boilerplate.git  <你的項目名字>

切換到目錄下：

cd <span class="hljs-tag">&lt;<span class="hljs-name">你的項目名字</span>&gt;</span>

一般來說，接下來運行 npm run install 安裝項目的依賴後，就可以運行；有些模板可能有內置的初始化命令，比如 react-boilerplate：

npm run setup

啓動應用：

npm start

這時，就可以在瀏覽器中預覽應用了。

1.2 使用命令行創建

這種方式需要安裝相應的命令，然後由命令來創建項目。

以 create-react-app 爲例：

安裝命令：

npm install -g create-react-app

創建項目：


create-react-app my-app

運行應用：

cd my-app
npm start

1.3 自己搭建項目骨架

如果你需要定製化，可以選擇自己搭建項目的骨架，但這需要開發者對構建工具如 webpack、npm、node 及其生態等有相當的瞭解與應用，才能完美的把控整個項目。

下面將會一步一步的說明如何搭建一個定製化的項目骨架。

2. 選擇合適的規範來寫代碼

js 模塊化的發展大致有這樣一個過程 iife => commonjs/amd => es6，而在這幾個規範中：

iife: js 原生支持，但一般不會直接使用這種規範寫代碼
amd: requirejs 定義的加載規範，但隨着構建工具的出現，便一般不會用這種規範寫代碼
commonjs: node 的模塊加載規範，一般會用這種規範寫 node 程序
es6: ECMAScript2015 定義的模塊加載規範，需要轉碼後瀏覽器才能運行

這裏推薦使用 es6 的模塊化規範來寫代碼，然後用工具轉換成 es5 的代碼，並且 es6 的代碼可以使用 Tree shaking 功能。

參考：

3. 選擇合適的構建工具

對於前端項目來說，構建工具一般都選用 webpack，webpack 提供了強大的功能和配置化運行。如果你不喜歡複雜的配置，可以嘗試 parcel。

參考：

webpack 之外的另一種選擇：parcel

4. 確定是單頁面應用（SPA）還是多頁面應用

因爲單頁面應用與多頁面應用在構建的方式上有很大的不同，所以需要從項目一開始就確定，使用哪種模式來構建項目。

4.1 多頁面應用

傳統多頁面是由後端控制一個 url 對應一個 html 文件，頁面之間的跳轉需要根據後端給出的 url 跳轉到新的 html 上。比如：

http://www.example.com/page1 -> path/to/page1.html
http://www.example.com/page2 -> path/to/page2.html
http://www.example.com/page3 -> path/to/page3.html

這種方式的應用，項目裏會有多個入口文件，搭建項目的時候就需要對這種多入口模式進行封裝。另外，也可以選擇一些封裝的多入口構建工具，如 lila。

4.2 單頁面應用

單頁面應用（single page application），就是隻有一個頁面的應用，頁面的刷新和內部子頁面的跳轉完全由 js 來控制。

一般單頁面應用都有以下幾個特點：

本地路由，由 js 定義路由、根據路由渲染頁面、控制頁面的跳轉
所有文件只會加載一次，最大限度重用文件，並且極大提升加載速度
按需加載，只有真正使用到頁面的時候，才加載相應的文件

這種方式的應用，項目裏只有一個入口文件，便無需封裝。

參考：

單頁面應用（SPA）、按需加載

5. 選擇合適的前端框架與 UI 庫

一般在搭建項目的時候就需要定下前端框架與 UI 庫，因爲如果後期想更換前端框架和 UI 庫，代價是很大的。

比較現代化的前端框架：

一些不錯的組合：

jquery + bootstrap：比較經典的
react + ant-design、material-ui、Semantic-UI：react 的組合
vue + element、iview、vux、mint-ui：vue 的組合

6. 定好目錄結構

一個好的目錄結構對一個好的項目而言是非常必要的。

一個好的目錄結構應當具有以下的一些特點：

解耦：代碼儘量去耦合，這樣代碼邏輯清晰，也容易擴展
分塊：按照功能對代碼進行分塊、分組，並能快捷的添加分塊、分組
編輯器友好：需要更新功能時，可以很快的定位到相關文件，並且這些文件應該是很靠近的，而不至於到處找文件

比較推薦的目錄結構：

多頁面應用

|-- src/ 源代碼目錄

    |-- page1/ page1 頁面的工作空間（與這個頁面相關的文件都放在這個目錄下）
        |-- index.html html 入口文件
        |-- index.js js 入口文件
        |-- index.(css|less|scss) 樣式入口文件
        |-- html/ html 片段目錄
        |-- (css|less|scss)/ 樣式文件目錄
        |-- mock/ 本地 json 數據模擬
        |-- images/ 圖片文件目錄
        |-- components/ 組件目錄（如果基於 react, vue 等組件化框架）
        |-- ...

    |-- sub-dir/ 子目錄
        |-- page2/ page2 頁面的工作空間（內部結構參考 page1）
            |-- ...

    |-- ...

|-- html/ 公共 html 片段
|-- less/ 公共 less 目錄
|-- components/ 公共組件目錄
|-- images/ 公共圖片目錄
|-- mock/ 公共 api-mock 文件目錄
|-- ...

單頁面應用

|-- src/ 源代碼目錄
    |-- page1/ page1 頁面的工作空間
        |-- index.js 入口文件
        |-- services/ service 目錄
        |-- models/ model 目錄
        |-- mock/ 本地 json 數據模擬
        |-- images/ 圖片文件目錄
        |-- components/ 組件目錄（如果基於 react, vue 等組件化框架）
        |-- ...

    |-- module1/ 子目錄
        |-- page2/ page2 頁面的工作空間（內部結構參考 page1）

    |-- ...

|-- images/ 公共圖片目錄
|-- mock/ 公共 api-mock 文件目錄
|-- components/ 公共組件目錄   
|-- ...

7. 搭建一個好的腳手架

搭建一個好的腳手架，能夠更好的編寫代碼、構建項目等。

|-- /                              項目根目錄
    |-- src/                       源代碼目錄
    |-- package.json               npm 項目文件
    |-- README.md                  項目說明文件
    |-- CHANGELOG.md               版本更新記錄
    |-- .gitignore                 git 忽略配置文件
    |-- .editorconfig              編輯器配置文件
    |-- .npmrc                     npm 配置文件
    |-- .npmignore                 npm 忽略配置文件
    |-- .eslintrc                  eslint 配置文件
    |-- .eslintignore              eslint 忽略配置文件
    |-- .stylelintrc               stylelint 配置文件
    |-- .stylelintignore           stylelint 忽略配置文件
    |-- .prettierrc                prettier 配置文件
    |-- .prettierignore            prettier 忽略配置文件

    |-- .babelrc                   babel 配置文件
    |-- webpack.config.js          webpack 配置文件
    |-- rollup.config.js           rollup 配置文件
    |-- gulpfile.js                gulp 配置文件

    |-- test/                      測試目錄
    |-- docs/                      文檔目錄
    |-- jest.config.js             jest 配置文件
    |-- .gitattributes             git 屬性配置

.``editorconfig: 用這個文件來統一不同編輯器的一些配置，比如 tab 轉 2 個空格、自動插入空尾行、去掉行尾的空格等，http://editorconfig.org
eslint、stylelint、prettier: 規範化代碼風格、優化代碼格式等
husky、lint-staged: 在 git 提交之前對代碼進行審查，否則不予提交
.gitlab-ci.yml: gitlab ci 持續集成服務

參考：

========================

到這裏爲止，一個基本的項目骨架就算搭建好了。

8. 使用版本控制系統管理源代碼（git）

項目搭建好後，需要一個版本控制系統來管理源代碼。

比較常用的版本管理工具有 git、svn，現在一般都用 git。

一般開源的項目可以託管到 http://github.com，私人的項目可以託管到 https://gitee.com、https://coding.net/，而企業的項目則需要自建版本控制系統了。

自建版本控制系統主要有 gitlab、gogs、gitea：gitlab 是由商業驅動的，比較穩定，社區版是免費的，一般建議選用這個；gogs, gitea 是開源的項目，還不太穩定，期待進一步的更新。

所以，git + gitlab 是不錯的配合。

9. 編寫代碼

編寫代碼時，js 選用 es6 的模塊化規範來寫（如果喜歡用 TypeScript，需要加上 ts-loader），樣式可以用 less、scss、css 來寫。

寫 js 模塊文件時，註釋可以使用 jsdoc 的規範來寫，如果配置相應的工具，可以將這些註釋導出接口文檔。

因爲腳手架裏有 husky、lint-staged 的配合，所以每次提交的代碼都會進行代碼審查與格式優化，如果不符合規範，則需要把不規範的代碼進行修改，然後才能提交到代碼倉庫中。

比如 console.log(haha.hehe); 這段代碼就會遇到錯誤，不予提交：

這個功能定義在 package.json 中：

{
  "devDependencies": {             工具依賴
    "babel-eslint": "^8.2.6",
    "eslint": "^4.19.1",
    "husky": "^0.14.3",
    "lint-staged": "^7.2.0",
    "prettier": "^1.14.0",
    "stylelint": "^9.3.0",
    "eslint-config-airbnb": "^17.0.0",
    "eslint-config-prettier": "^2.9.0",
    "eslint-plugin-babel": "^5.1.0",
    "eslint-plugin-import": "^2.13.0",
    "eslint-plugin-jsx-a11y": "^6.1.0",
    "eslint-plugin-prettier": "^2.6.2",
    "eslint-plugin-react": "^7.10.0",
    "stylelint-config-prettier": "^3.3.0",
    "stylelint-config-standard": "^18.2.0"
  },
  "scripts": {                     可以添加更多命令
    "precommit": "npm run lint-staged",
    "prettier": "prettier --write "./**/*.{js,jsx,css,less,sass,scss,md,json}"",
    "eslint": "eslint .",
    "eslint:fix": "eslint . --fix",
    "stylelint": "stylelint "./**/*.{css,less,sass,scss}"",
    "stylelint:fix": "stylelint "./**/*.{css,less,sass,scss}" --fix",
    "lint-staged": "lint-staged"
  },
  "lint-staged": {                 對提交的代碼進行檢查與矯正
    "**/*.{js,jsx}": [
      "eslint --fix",
      "prettier --write",
      "git add"
    ],
    "**/*.{css,less,sass,scss}": [
      "stylelint --fix",
      "prettier --write",
      "git add"
    ],
    "**/*.{md,json}": [
      "prettier --write",
      "git add"
    ]
  }
}

如果你想禁用這個功能，可以把 scripts 中 "precommit" 改成 "//precommit"
如果你想自定 eslint 檢查代碼的規範，可以修改 .eslintrc, .eslintrc.js 等配置文件
如果你想自定 stylelint 檢查代碼的規範，可以修改 .stylelintrc, .stylelintrc.js 等配置文件
如果你想忽略某些文件不進行代碼檢查，可以修改 .eslintignore, .stylelintignore 配置文件

10. 組件化

當項目擁有了一定量的代碼之後，就會發現，有些代碼是很多頁面共用的，於是把這些代碼提取出來，封裝成一個組件，供各個地方使用。

當擁有多個項目的時候，有些組件需要跨項目使用，一種方式是複製代碼到其他項目中，但這種方式會導致組件代碼很難維護，所以，一般是用另一種方式：組件化。

組件化就是將組件獨立成一個項目，然後在其他項目中安裝這個組件，才能使用。

一般組件化會配合私有 npm 倉庫一起用。

|-- project1/ 項目1
    |-- package.json

|-- project2/ 項目2
    |-- package.json    

|-- component1/ 組件1
    |-- package.json

|-- component2/ 組件2
    |-- package.json

在 project1 中安裝 component1， component2 組件：

# package.json
{
  "dependencies": {
    "component1": "^0.0.1",
    "component2": "^0.0.1"
  }
}

import compoennt1 from 'compoennt1';
import compoennt2 from 'compoennt2';

11. 測試

測試的目的在於能以最少的人力和時間發現潛在的各種錯誤和缺陷，這在項目更新、重構等的過程中尤其重要，因爲每當更改一些代碼後，你並不知道這些代碼有沒有問題、會不會影響其他的模塊。如果有了測試，運行一遍測試用例，就知道更改的代碼有沒有問題、會不會產生影響。

一般前端測試分以下幾種：

單元測試：模塊單元、函數單元、組件單元等的單元塊的測試
集成測試：接口依賴（ajax）、I/O 依賴、環境依賴（localStorage、IndexedDB）等的上下文的集成測試
樣式測試：對樣式的測試
E2E 測試：端到端測試，也就是在實際生產環境測試整個應用

一般會用到下面的一些工具：

另外，可以參考聊聊前端開發的測試。

12. 構建

一般單頁面應用的構建會有 npm run build 的命令來構建項目，然後會輸出一個 html 文件，一些 js/css/images ... 文件，然後把這些文件部署到服務器就可以了。

多頁面應用的構建要複雜一些，因爲是多入口的，所以一般會封裝構建工具，然後通過參數傳入多個入口：

npm run build -- page1 page2 dir1/* dir2/all --env test/prod

page1, page2 確定構建哪些頁面；dir1/*, dir2/all 某個目錄下所有的頁面；all, * 整個項目所有的頁面
有時候可能還會針對不同的服務器環境（比如測試機、正式機）做出不同的構建，可以在後面加參數
-- 用來分割 npm 本身的參數與腳本參數，參考 npm – run-script 瞭解詳情

多頁面應用會導出多個 html 文件，需要注意這些導出的 html 不要相沖突了。

當然，也可以用一些已經封裝好的工具，如 lila。

13. 部署

在構建好項目之後，就可以部署到服務器了。

傳統的方式，可以用 ftp, sftp 等工具，手動傳到服務器，但這種方式比較笨拙，不夠自動化。

自動化的，可以用一些工具部署到服務器，如 gulp、gulp-ssh，當然也可以用一些封裝的工具，如 md-sync、lila 等

以 md-sync 爲例：

npm install md-sync --save-dev

md-sync.config.js 配置文件：

module.exports = [
  {
    src: './build/**/*',
    remotePath: 'remotePath',
    server: {
      ignoreErrors: true,
      sshConfig: {
        host: 'host',
        username: 'username',
        password: 'password'
      }
    },
  },
  {
    src: './build/**/*.html',
    remotePath: 'remotePath2',
    server: {
      ignoreErrors: true,
      sshConfig: {
        host: 'host',
        username: 'username',
        password: 'password'
      }
    },
  },
];

在 package.json 的 scripts 配置好命令：

"scripts": {
  "deploy": "md-sync"
}

npm run deploy

另外，一般大型項目會使用持續集成 + shell 命令（如 rsync）部署。

14. 持續集成測試、構建、部署

一般大型工程的的構建與測試都會花很長的時間，在本地做這些事情的話就不太實際，這就需要做持續集成測試、構建、部署了。

持續集成工具用的比較多的：

jenkins 是通用型的工具，可以與 github、bitbucket、gitlab 等代碼託管服務配合使用，優點是功能強大、插件多、社區活躍，但缺點是配置複雜、使用難度較高。

gitlab ci 是 gitlab 內部自帶的持續集成功能，優點是使用簡單、配置簡單，但缺點是不及 jenkins 功能強大、綁定 gitlab 才能使用。

以 gitlab 爲例（任務定義在 .gitlab-ci.yml 中）：

stages:
  - install
  - test
  - build
  - deploy

# 安裝依賴
install:
  stage: install
  only:
    - dev
    - master
  script:
    - npm install

# 運行測試用例
test:
  stage: test
  only:
    - dev
    - master
  script:
    - npm run test

# 編譯
build:
  stage: build
  only:
    - dev
    - master
  script:
    - npm run clean
    - npm run build

# 部署服務器
deploy:
  stage: deploy
  only:
    - dev
    - master
  script:
    - npm run deploy

以上配置表示只要在 dev 或 master 分支有代碼推送，就會進行持續集成，依次運行：

npm install
npm run test
npm run clean
npm run build
npm run deploy

最終完成部署。如果中間某個命令失敗了，將停止接下的命令的運行，並將錯誤報告給你。

這些操作都在遠程機器上完成。

===================

到這裏爲止，基本上完成了一個項目的搭建、編寫、構建。

15. 清理服務器上過期文件

現在前端的項目基本上都會用 webpack 打包代碼，並且文件名（html 文件除外）都是 hash化的，如果需要清除過期的文件而又不想把服務器上文件全部刪掉然後重新構建、部署，可以使用 sclean 來清除過期文件。

16. 收集前端錯誤反饋

當用戶在用線上的程序時，怎麼知道有沒有出 bug；如果出 bug 了，報的是什麼錯；如果是 js 報錯，怎麼知道是那一行運行出了錯？

所以，在程序運行時捕捉 js 腳本錯誤，並上報到服務器，是非常有必要的。

這裏就要用到 window.onerror 了：

window.onerror = (errorMessage, scriptURI, lineNumber, columnNumber, errorObj) => {
  const data = {
    title: document.getElementsByTagName('title')[0].innerText,
    errorMessage,
    scriptURI,
    lineNumber,
    columnNumber,
    detailMessage: (errorObj && errorObj.message) || '',
    stack: (errorObj && errorObj.stack) || '',
    userAgent: window.navigator.userAgent,
    locationHref: window.location.href,
    cookie: window.document.cookie,
  };

  post('url', data); // 上報到服務器
};

線上的 js 腳本都是壓縮過的，需要用 sourcemap 文件與 source-map 查看原始的報錯堆棧信息，可以參考細說 js 壓縮、sourcemap、通過 sourcemap 查找原始報錯信息瞭解詳細信息。

自己是從事了五年的前端工程師

如果你依然在編程的世界裏迷茫，不知道自己的未來規劃，可以加入web前端學習交流羣：731771211 裏面可以與大神一起交流並走出迷茫。新手可進羣免費領取學習資料，看看前輩們是如何在編程的世界裏傲然前行！羣裏不停更新最新的教程和學習方法（進羣送web前端系統學習路線，詳細的前端項目實戰教學視頻），有想學習web前端的，或是轉行，或是大學生，還有工作中想提升自己能力的，正在學習的小夥伴歡迎加入

點擊：加入

手把手教你構建一個web前端項目，全網最詳細教程！

1. 選擇現成的項目模板還是自己搭建項目骨架

1.1 使用 `git` 直接克隆到本地

1.3 自己搭建項目骨架

2. 選擇合適的規範來寫代碼

3. 選擇合適的構建工具

4. 確定是單頁面應用（SPA）還是多頁面應用

4.1 多頁面應用

4.2 單頁面應用

5. 選擇合適的前端框架與 UI 庫

6. 定好目錄結構

8. 使用版本控制系統管理源代碼（git）

9. 編寫代碼

10. 組件化

11. 測試

12. 構建

13. 部署

14. 持續集成測試、構建、部署

15. 清理服務器上過期文件

16. 收集前端錯誤反饋

移位操作搞定兩數之商

如何基於surging跨網關跨語言進行緩存降級

2024合集

程序員天天 CURD，怎麼才能成長，職業發展的思考(2)

教你用Perl實現Smgp協議

如何通過前端表格控件在10分鐘內完成一張分組報表？

win11關閉自動檢測病毒刪文件

通用代碼生成器簡介

lightdb 單機模式下數據庫平移

千兆寬帶實際網速能到達多少？

一直在做業務的程序員技術會進步嗎？程序員如何跳出舒適圈

程序員修改那些喪心病狂的BUG，得知真香後瞬間崩潰！

5年前端開發程序員教你如何寫簡歷！看完別再問爲何你只值5K

程序員35歲後,不拼體力了還不能拼什麼？

程序員爲何如此受人追捧？是什麼在推動這個行業的發展

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結

手把手教你構建一個web前端項目，全網最詳細教程！

1. 選擇現成的項目模板還是自己搭建項目骨架

1.1 使用 git 直接克隆到本地

1.3 自己搭建項目骨架

2. 選擇合適的規範來寫代碼

3. 選擇合適的構建工具

4. 確定是單頁面應用（SPA）還是多頁面應用

4.1 多頁面應用

4.2 單頁面應用

5. 選擇合適的前端框架與 UI 庫

6. 定好目錄結構

8. 使用版本控制系統管理源代碼（git）

9. 編寫代碼

10. 組件化

11. 測試

12. 構建

13. 部署

14. 持續集成測試、構建、部署

15. 清理服務器上過期文件

16. 收集前端錯誤反饋

1.1 使用 `git` 直接克隆到本地