2.開發類
3.其他問題
專案中使用的是純ssr方案，以下非特指不包含靜態匯出方案
專案開發中使用gitlab的cicd 做持續整合，docker部署， 靜態檔案存放阿里雲oss。
有兩個目錄可以使用cdn 部署。乙個是打包生成的_next/static目錄。乙個是專案目錄中的static目錄。
_next/static存放的是打包產生的一些靜態資源，每次打包都會變更，有hash值。static存放專案的一些靜態資源，第三方的庫等。
cicd 執行完buildjob，取到_next/static和static目錄，上傳到阿里雲oss。
專案中需要修改配置（**中用到的環境變數會在1.1.4 中說明）
module.exports =
withbundleanalyzer
(withless(,
publicruntimeconfig:})
)
後面我們採用了docker 就沒有採用pm2 程序守護，每次打包都是全新的容器，都會重新啟動。
nextjs 本身支援的環境數量有限，支援四種環境[生產，開發，本地].env.production，.env.development，.env.local。直接在根目錄建這幾個檔案就好了。作者也做了解釋，通用環境就是這麼多，不打算做更多相容。
但是這顯然不滿足我們公司的所需的環境[本地，測試，預發布，生產]，因此引入cross-env,dotenv自定義環境。
yarn add cross-env dotenv -dnext.config.js
// 環境變數配置
const dotenv =
require
('dotenv'
)const envpath = process.env.
dot_env_file
?`.dotenv.$`
:'.dotenv.local'
const dotenvresult = dotenv.
config()
if(dotenvresult.error)
console.
log(
`[執行環境] *****==
$*****===`
)
//.dotenv.dev
next_public_apiurl=
//.dotenv.test
next_public_apiurl=
//.dotenv.pre
next_public_apiurl=
//.dotenv.prod
next_public_apiurl=
"scripts"
:,
process.env.
next_public_apiurl
登入完成後拿到token
每次請求的是否去cookie裡面去token，帶給後台就可以實現登入。這裡取token 跟 設定token 一樣不同端不同處理，服務端通過context 處理
推薦乙個庫 next-cookie 自動幫你處理，支援hooks 用法
// 安裝
yarn add next-cookie
// 使用
import
from
'next-cookie'
;const cookies =
usecookie
(context)
cookies.
set(
'xx_token'
,'******'
)
沒有很複雜的狀態管理不建議用redux，不是很好用大部分問題都還是react 配合 ts 的問題，nextjs 這塊基本還好，幾個宣告週期鉤子宣告即可。
import
from
'next'
export
const getstaticprops: getstaticprops =
async
(context)
=>
export
const getstaticpaths: getstaticpaths =
async()
=>
export
const getserversideprops: getserversideprops =
async
(context)
=>
next typescript
上線後，自己在看umi框架的時候發現umi支援ssr
umi 官方給出的umi 與 nextjs 對比。
next.js 是個很好的選擇，umi 很多功能是參考 next.js 做的。要說有哪些地方不如 umi，我覺得可能是不夠貼近業務，不夠接地氣。比如 antd、dva 的深度整合，比如國際化、許可權、資料流、配置式路由、補丁方案、自動化 external 方面等等一線開發者才會遇到的問題。umi 的優點就是簡單配置，開箱即用封裝了很多東西在裡面，你能省掉很大一部分折騰的實踐。文件以及社群都是中文的，還有一些論壇，im群都是國內的在溝通，溝通成本低。
缺點：umi ssr 大部分參考nextjs ，甚至除了框架本身，其他的庫也參考了，umi-request 基本上跟swr 差不多。目前的話最新的一些特性，肯定是nextjs 先有的。後續就看umi 的生態搞的怎麼樣了。
umi 預設預裝一堆沒用的外掛程式進去，有些外掛程式不用打包的時候也硬打進去了，移除時候有點兒麻煩
如果說有精力去踩坑，英文水平還可以的同學可以直接使用nextjs 方案，最新的特性，生態整個也比umi要好些。（中文文件是有些欠缺的）
想省事的話可以直接使用umi的（雖然最終不一定省事）
服務端渲染or預渲染
今天木有引言嚶嚶嚶 瀏覽器核心分兩個部分 渲染引擎 js引擎 解析html以構建dom樹 構建render樹 布局render樹 繪製render樹 不過有三個點需要注意 雖然能夠很快渲染出頁面，但是沒有執行react時頁面無法進行互動 獲取第乙個位元組時會更加慢一點，由於ssr需要將完整的渲染過的...
Node art template服務端渲染
http 模組 檔案處理模組 var fs require fs 建立服務例項 檔案路徑 var pathdir d hbuiderprojects nodejslearn resoure 監聽客戶端請求 server.on request function req,res console.log ...
服務端渲染總結
1.服務端渲染2個優點 和 缺點 1.1 服務端渲染可以減少白屏時間 服務端渲染，客戶端接收到html，可以直接顯示 客戶端渲染，客戶端接收到html，解析完畢，還要向服務端去請求js檔案，返回後，執行完js，才能顯示完成 因此，服務端渲染，白屏時間短。1.2 服務端渲染利於seo 有清晰的html...