1樓：JISOO
當然可以，但是彈性計算時代，伺服器成本這麼低，計算前置並不是首選方案。一切以成本考量。
業務一致性成本，前端包括但不限於pc web，移動端h5，安卓，ios，小程式，快應用等等等等，計算前置意味著主動犧牲了一定程度的業務一致性，導致前端人工成本上公升。
客戶體驗成本，總體來說後台效能可控而客戶機效能是不可控的，萬一客戶機器本身不太好，壓力前置可能導致使用者體驗捉雞。
2樓：牆外一枝花
要看會不會增加額外的網路通訊，如果沒有那可能可以減輕伺服器的cpu壓力，不然不僅沒有減輕伺服器原有的壓力，還可能增加通訊壓力，然後進一步增加了cpu壓力，所以這個問題要具體問題具體分析，切忌想當然
3樓：黃明
單純說日期格式化的話，我覺得：前後端資料交換時，只需保持簡單/統一的資料格式即可，例如時間資料都以標準格式"2000-01-01 00:00:
00"這樣的格式傳遞，具體需要為使用者呈現什麼樣的日期，由前端來解析後來決定格式化成什麼樣。
除此之外，還有許多其他計算工作可以放在使用者裝置上運算，有些不單單是為了減輕伺服器的壓力。
舉個不恰當的例子（因為我不確定由瀏覽器完成了計算工作，雖然我覺得放在瀏覽器上執行應該也行 :P ），bilibili的彈幕蒙版:
動畫彈幕蒙版功能測試以及方法介紹
像深度學習這樣繁重的任務都可以由瀏覽器來完成了，所以題主可以想得再大膽一些 [奸笑]
4樓：零式改
不存在使用者量大怎麼怎麼滴，才上千而已，因為效能瓶頸基本還在I/O上。而且業務邏輯和介面邏輯的交叉，維護成本和溝通成本夠你喝一壺。
5樓：Leo.wei
前端頁面更多體現在view層，也就是負責互動和渲染，這樣更加純粹，如果你想前端自己來處理，可以搞個bff，現成的框架很多，不過需要一些運維成本，這個也是目前很多公司搞serverless的出發點，可以了解下
6樓：和尚
理論上是可以的，js挖礦馬了解下。
實際上，
先問問前端幹不幹
再問問安全批不批
再問問老闆，費功夫幹的這些事，加一台伺服器能不能搞定
7樓：智伍應用
是的，把一些計算放在客戶端瀏覽器，這樣伺服器就不用計算了，是可以減輕伺服器壓力的！！現在都流行服務端就輸出json資料，然後客戶端呼叫資料，然後在客戶端顯示！！
8樓：hubeen
光是格式化資料，對伺服器造成的壓力微乎其微，不必糾結這種細節。前端最大的問題是沒數，你算什麼呢。前端能做的一般是弱資料依賴的類桌面應用程式，比如繪個圖表，畫個3d模型，做個excel。
強資料依賴的別想了。
9樓：時一
可行,理論上來說可以提公升服務的併發能力.
但是實際上提公升效果微乎其微,因為目前大部分的服務,其效能瓶頸不在這裡,主要集中在一些跨程序或者跨機器的服務呼叫與訪問上,比如資料庫查詢,快取訪問,檔案訪問等.
10樓：折瑩
作為一名前端我覺得計算類的東西還是放在伺服器比價好，我們瀏覽器計算節點資訊，繪製已經是「任務繁重了」，所以可以伺服器端計算的盡量放在伺服器端，如果這樣還壓力很大的話，那就要考慮一下這個計算本身的演算法了
11樓：一點點水
當然了，伺服器的活給客戶端做了，當然能輕鬆。不過一般壓力都在資料庫，所以實際上這些小任務誰來做大家可能都不是很在意，但是有這個想法是極好的。
12樓：小破孩不會程式設計序
C/S架構下，一件事情不是前端做就是後端做。
這個其實是這個問題的本質。事情你讓前端做了，我後端的壓力就減輕了。而且不僅僅是減輕的是伺服器的CPU壓力哦，因為你不告訴我事情了，網路壓力也減輕了。
但事情由前端做和後端做是不一樣的。前端做是分布式的，因為前端的裝置分散在各個地方，所以他的做事成本是比較低的。後端是集中式的，如果海量的併發進來，我都需要算一遍之後再給你，那我後端的CPU壓力、網路壓力甚至這個計算帶來的資料讀寫的IO壓力，都會很大。
所以如果從減輕伺服器壓力的角度來講，這個答案就是肯定的。
所以很多時候，考慮問題不是乙個維度的，是乙個平衡的結果。減輕的伺服器壓力如果在核心資料的安全面前，那其實一文不值...
13樓：琴梨梨
是比如我們來看乙個經典的例子
這個頁面可以把svg轉換為Android向量xml這是乙個完全靜態的頁面，它沒有伺服器，它只是託管在github pages上
它完全使用js，讀取並處理檔案
以及包括像基於套殼的nwjs，electron等等，都是前端計算的典例
你看，把計算放在前端甚至可以實現無伺服器執行
14樓：回形針
取決於計算的結果的真實性有多重要
前端不管怎麼保護，都應該假設收到的所有資料都有可能是偽造的，並以這個為前提去設計後端和整個業務流程
所以如果資料被篡改不會影響到發出請求的使用者以外的使用者或者記錄，那就完全可以放在前端（比如其他答主說過的從excel提取需要的資料
如果資料的真實性非常重要（比如極端一點 token的許可權和有效期）那就必須放在後端驗證，即使這個驗證看起來特別簡單特別蠢
但總而言之，能放前端的東西盡量放前端，給後端減負對大家都有好處不是。。。。。
15樓：aFlappyPig
如果單就問題來說的話，確實是可以減輕伺服器壓力的，具體效果的話因情況而異。
併發很高的情況其實並不總是存在，往往是一瞬間的，如果真的是幾個日期格式化這種的，對於伺服器的影響幾乎是不可感知的。
能放在前端的，一是非實時的，二是不重要的資料，三是對使用者體驗影響較小的。非實時是因為前端資料不能保證總是準確的，重要資料一般需要後端二次校驗和許可權控制，所以這些都不能放在前端。使用者體驗這點的話，對於很多專案是很在意的，所以現在很多專案做了spa又開始搞ssr，其實就是用伺服器資源（加大成本）換取使用者體驗。
16樓：shuhari
舉個反面的例子。像 12306、以及秒殺這樣的場景，伺服器壓力是非常大的，但是這個壓力不可能由前端來分擔，因為前端根本不具備計算所需的條件。至於顯示、格式化這類工作，本來就是前端分內的職責，根本問題是修正從前不合理的分工，減輕伺服器壓力只是附帶影響。
如果真要把部分計算工作放到前端，你應當考慮到客戶端平台多樣化的問題、前端團隊能不能 Hold 得住需求，以及客戶端環境是否可靠等等，只有這些問因素評估過且認定收益大於成本，才值得去修改，否則有可能是得不償失的。
17樓：annbbn
1. 前後端分離後需要找準這個分界線，業務邏輯計算相關統統放在後端，前端只處理渲染邏輯計算
2. 還要約定介面規範，拿題主舉得例子來說，日期顯示，如果約定了前端處理展示，那後端介面是不是統一都返回時間戳，前端封裝方法展示不同格式，介面規範最好在專案初期就約定好，避免後期修改存量介面的成本，如果不改，那存量和增量就不對應了
3. 一般來說計算盡量放在後端，伺服器計算比客戶端來的快，服務端很多計算再加上快取，不會那麼容易壓垮服務
18樓：一郭鮮
這種說法或做法是絕對不可取的。
前端處理計算邏輯只是表面工作，短時間內讓使用者體驗無異常，但時間久一點一定會出現不可控「局面」。
在前端處理業務計算邏輯帶來的影響:
資料可能會隨前端頁面的狀態而出現異常；
資料安全性極低，甚至沒有安全性可言，尤其涉及到貨幣交易，使用者可以隨意修改資料，盜刷貨幣
光憑這兩點就可以明確前端代替服務端做運算完全不可取。
19樓：「已登出」
如果是計算顯示結果的話可以這樣做的，不對後端資料造成影響。還有就是後端服務的有幾個產品的話，也不建議，計算在要寫很多遍，改個計算邏輯也很麻煩，修改一下全部都要改
如果是前端計算乙個結果傳給後端的話，就非常不建議，傳過去後端也要驗證下資料，才敢往資料庫懟
20樓：superior
說實話，會減輕壓力，但是不靠譜，舉個例子金額計算這種交給前端去幹，必然會有坑點
個人感覺應該做好分工，哪部分由前端去幹，哪部分由後端去幹
最後要注意一點，交給前端處理部分邏輯也會增加使用者等待時長，使用者體驗也會有部分下降（畢竟伺服器計算要比客戶端計算快多了）
21樓：布魯斯
雙刃劍！
1. 這個前段如果有發布，審核，進市場的過程。那麼如果前端出問題了以後的修復就很麻煩了。
最好是通過前後端使用合適的快取策略來達到提高效率的效果。而不是單純的把計算放在前端來處理。
2. 各個業務端如果使用了相同邏輯，而這部分邏輯有分別放在不同端也需要注意
22樓：佚樹
誰都可以做,要權衡的是開發和維護成本:
如果只有Web端, 單頁內的很多業務邏輯計算和數值轉換都可以放到前端來做, 大致就是後端注重資料, 前端注重業務.
如果是多平台前端, 尤其是需要單獨開發、使用者需要手動更新的客戶端, 那就盡可能讓前端只保留基本的互動和展示功能.
當然還跟具體的專案型別、公司前後端人員佔比等等實際因素有關.
23樓：圈鵝
按照資料的重要敏感程度有些處理是要服務端做收口的。
但是大部分情況，前後端誰做都可以後端做：可能會增加一些處理的計算量，導致處理的時間延長前端做：可能會增加前端處理邏輯，導致影響使用者的使用體驗綜上可以看到，沒有絕對的一定要哪一方做，哪一方有損耗都不好，要看具體的場景（和battle）進行取捨。
所以不如換個思路：比如如何通過端上的一些快取策略減少請求？面對高併發場景如何進行處理優化。
這些顯然比某欄位處理需要前端做還是後端做有意義
24樓：海淀遊民
技術上可以，但是後患無窮，得不償失。
各個瀏覽器有差異，適配工作量和相關測試的難度翻著倍的增加。
安全問題不好解決，商業資料殘留在外面是重大安全隱患。
邏輯複雜度迅速增加，業務邏輯被切割在不同的地方，很難開發測試。
總之，表現層就是表現層，不要加戲給它自己給自己找麻煩。
25樓：時代Java
可以減輕伺服器壓力。
但是會增加前端頁面的開發量。
再有就是增加不確定性，比如日期格式化，由於客戶端不同，可能前端頁面計算完後，顯示的日期格式有差異。
所以計算放在前端頁面有利有弊。
26樓：plusGo
在遵守安全開發的前提下，再來回答此問題。
1、前端在計算密集IO和網路IO取乙個平衡，任何一方偏多都不太好。
2、對前端開發人員的要求會提高，不只是簡單的頁面邏輯了，還會涉及到資料流轉邏輯，需要考慮這一部分的人力溝通成本。
3、這和另乙個問題有一些關聯「標準的後端API」，面對不同的終端的需求，資料糅雜可以讓各個終端來使用。
如何將 HTML 頁面（React實現）的一部分轉成 PDF ？
待宰的豬 其中樣式用react inline css這個庫轉化為內聯樣式 最後用html to pdf這個外掛程式轉化成pdf？ 破滅訣 let exportPdf this.refs.exportPdf document find body html exportPdf window.print ...
英語是漢語的一部分嗎？
秦文軒 如果題主的問題是認真的話，那麼我也給出認真的回答吧。英語和漢語是兩種不同的語言，兩者之一從來都不是，也永遠不會是對方的一部分。題主需要注意一點，語言 和 文字 是兩個不同的概念。英語使用拉丁字母書寫，漢語使用漢字書寫。但拉丁字母不僅僅用於英語的書寫，漢字也不僅僅用於漢語的書寫。就前者來說，法...
愛情是生活的一部分還是全部
果果 作為生活的一部分就已經足夠，你不能指望愛情是每天保持新鮮的，但是生活確是每天都不同，在於我們看待的心情，態度。作為生活的全部那樣會輸得很慘，不管是七年之癢還是更久，總會有磕磕絆絆，你指望為愛情而活，那你就會永遠惡性迴圈，受折磨的只有自己，只有跳出愛情所帶給你的甜蜜圈，你才會真正認清楚生活是多麼...