abstract：1、后端渲染實(shí)現(xiàn)：后端拼字符串唄…… （理論上后端模板也是字符串）好處：模板統(tǒng)一在后端。前端（相對(duì)）省事，不占用客戶端運(yùn)算資源（解析模板），只要不大改結(jié)構(gòu)，文字啥的小修改后端改了就好了。壞處：占用（部分、少部分）服務(wù)器運(yùn)算資源、，response 出的數(shù)據(jù)量會(huì)（稍）大點(diǎn)，模板改了前端的交互和樣式什么的一樣得跟著聯(lián)動(dòng)修改。2、前端模板實(shí)現(xiàn)：看這個(gè)吧……關(guān)于模板引擎的工作方式和性能？ - 前端開(kāi)發(fā) 但

1、后端渲染

實(shí)現(xiàn)：后端拼字符串唄…… （理論上后端模板也是字符串）
好處：模板統(tǒng)一在后端。前端（相對(duì)）省事，不占用客戶端運(yùn)算資源（解析模板），只要不大改結(jié)構(gòu)，文字啥的小修改后端改了就好了。
壞處：占用（部分、少部分）服務(wù)器運(yùn)算資源、，response 出的數(shù)據(jù)量會(huì)（稍）大點(diǎn)，模板改了前端的交互和樣式什么的一樣得跟著聯(lián)動(dòng)修改。

2、前端模板
實(shí)現(xiàn)：看這個(gè)吧……關(guān)于模板引擎的工作方式和性能？ - 前端開(kāi)發(fā) 但不僅限于正則替換這一招，掃token 生成語(yǔ)法樹(shù)，再根據(jù)語(yǔ)法樹(shù)拼接也行，或者使用 DOM 模板，借助 DOM API 處理也行，反正招兒多了去了。
好處：不占用服務(wù)端運(yùn)算資源（解析模板），模板在前端（很有可能僅部分在前端），改結(jié)構(gòu)變交互都前端自己來(lái)了，改完自己調(diào)就行。不用麻煩后端再聯(lián)調(diào)神馬的。
壞處：占用（一部分、少部分）客戶端運(yùn)算資源（解析模板）。前端代碼多點(diǎn)，畢竟包含模板代碼了么。腳本是不是首次下就慢點(diǎn)了（看你在意不在意這個(gè)畢竟能304和CDN啥的）?？赡茉斐汕昂髢煞菽０宓那闆r，總歸要后端吐出個(gè)首屏啥的先讓用戶看見(jiàn)吧。那這部分頁(yè)面模板不就是后端拼好了吐出來(lái)的么。

3、jquery的html，append等方法（包括瀏覽器原生相關(guān)DOM API）
實(shí)現(xiàn)：……這就不說(shuō)了吧，不就是直接插內(nèi)容或者DOM節(jié)點(diǎn)么。除非后端是直接吐出拼好的頁(yè)面，否則不關(guān)后端是通過(guò)接口吐的html字符串還是模板數(shù)據(jù)，怎么著不都得是通過(guò)這些玩意整頁(yè)面里去么。
好處：（興許是）靈活…… 還有因?yàn)橐桓妥油钡降琢?，直接使用（前端可控的）最終API，所以除了是后端直接吐的頁(yè)面外，這種方式是（相對(duì)）執(zhí)行效率最高的……
壞處：各種字符串和DOM節(jié)點(diǎn)拼來(lái)拼去真的很煩……