一、前言
二、介面**版本規範
考慮到介面今後一定會進行版本迭代，因此一開始開發的時候，就需要對**進行版本考量下的**目標架構。
1. 控制器目錄架構：
在controller下增加子集資料夾：controller/v1/……、controller/v2/……等等，初始版本的介面全部放在v1下。
2. 介面路由設計
v1版本介面路由：/v1/login
v2版本介面路由：/v2/login
遵循以上分類原則，依次遞推，嚴格區分不同版本介面**，結合下一部分的介面文件，利於不同版本介面更新維護。
三、不同版本介面文件規範
| —— 文件快捷導航
| —— 產品互動流程
| —— v1版本
| —— v2版本
| —— ……
| —— 文件規範
| —— 介面規範（介面位址，請求方式，介面引數，響應引數）
| —— 介面文件規範
| —— ……
| —— 開發計畫
| —— 全域性狀態碼
| —— 【v1】api文件
| —— v1介面更新日誌
| —— 使用者模組
| —— 裝置模組
| —— 【v2】api文件
| —— v2介面更新日誌
| —— 使用者模組
| —— 裝置模組
路由說明
/v1/login（帶指向介面文件的鏈結）
使用者登入
/v1/user/info（帶指向介面文件的鏈結）
獲取使用者詳情
……【v2】api [文件說明(帶鏈結)] [更新日誌(帶鏈結)]
路由說明
/v2/login（帶指向介面文件的鏈結）
使用者登入
/v2/user/info（帶指向介面文件的鏈結）
獲取使用者詳情
…… 2.全域性狀態碼：根據介面、推送等不同板塊業務需求，對不同業務下的介面設計不同數字段的狀態碼，遇到這樣設計下的狀態碼，溝通或出現問題更容易定位介面，如：
指定200為正確響應狀態碼，500為伺服器異常響應狀態碼；
其他情況下，根據業務模組區分，使用者功能相關介面非正確響應狀態碼指定1001~1050；裝置操作功能模組非正確響應狀態碼指定1051~1100，以此類推。
格式如下：
日期【年-月-日】
……如：
2019-04-22
1. 使用者模組：使用者登入，增加必要上報引數type；
2. 裝置模組：新增裝置，增加響應引數name欄位；
……2019-04-25
1. 使用者模組：使用者登入，增加必要上報引數type；
2. 裝置模組：新增裝置，增加響應引數name欄位；
……
如何優雅的管理不同版本的API介面
api版本管理方式多種多樣 序號版本管理方式 簡要說明 1網域名稱區分管理 不同版本使用不同網域名稱，v1.api.amap.com，v2.api.amap.com 2請求url path區分管理 同一網域名稱，api.amap.com v1 api.amap.com v2 3請求引數區分管理 同一...
如何更優雅地切換Git分支
在日常開發中，我們經常需要在不同的 git 分支之間來回切換，特別是業務需求比較多的開發人員。在分支較多的情況下，分支名的 tab 自動補全會比較糟糕，切換時我們不免需要複製或手打分支名，那麼有沒有更優雅的方式了呢？為了提高切換 git 分支的效率，我用 golang 寫了git checkout ...
如何更優雅地切換Git分支
在日常開發中，我們經常需要在不同的 git 分支之間來回切換，特別是業務需求比較多的開發人員。在分支較多的情況下，分支名的 tab 自動補全會比較糟糕，切換時我們不免需要複製或手打分支名，那麼有沒有更優雅的方式了呢？為了提高切換 git 分支的效率，我用 golang 寫了git checkout ...