有个金额数据加千分位是应该前端处理还是后端处理好？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 829 天前的主题，其中的信息可能已经有所发展或是发生改变。

今天开发遇到一个场景，前端页面里涉及金额的字段要增加千分位逗号，数据要做下处理，

我的疑问是，这个处理应该前端来做还是后端来做？

宝子们给点意见

先说下我自己的看法，我是前端的，所以我偏向前端只做交互和渲染，不做数据处理，应该后端处理数据，你们怎么看？

第 1 条附言 · 2022-08-04 13:44:19 +08:00

楼主遇到的场景是前端 H5 ，目前已经妥协进行前端处理了..

此贴沉了，感谢各位的发言~

处理

前端

宝子

数据

49 条回复 • 2022-08-08 22:52:42 +08:00

vikaptain

2022-08-04 10:40:37 +08:00

前端处理。这不是数据处理问题，是数据显示问题

abc0123xyz

2022-08-04 10:41:27 +08:00

只要不让我处理就好

stoluoyu

2022-08-04 10:41:54 +08:00

撕逼输了的处理

lingxiaoli

2022-08-04 10:43:06 +08:00

当然是前端来处理了 1 楼说的对这是显示问题

ngrok111

2022-08-04 10:43:52 +08:00

前端，就像一楼说的这是显示问题，后端给纯数字你想怎么改都行

cydysm

2022-08-04 10:43:54 +08:00 via iPhone

就一个字段的话前端
当然后端可以给个展示用的字段

MrdotX

2022-08-04 10:45:17 +08:00

@vikaptain
@lingxiaoli
@cydysm 那如果像是金额精度处理呢，应该前端还是后端处理？

thinkershare

2022-08-04 10:45:20 +08:00

屁股决定脑袋, 当然是希望将所有工作对推给对方做.
正常情况, 没有 BFF 肯定是所作都可以, 这个一个数据显示为什么样的样式, 更合理的当然是前端来做.

laviris

2022-08-04 10:45:28 +08:00

无论从哪个角度看都是前端处理

daimubai

2022-08-04 10:45:32 +08:00

数据显示问题当然是前端改。和时间一样的。后端给前端时间戳，前端展示年月日也好，时分秒也好

des

2022-08-04 10:46:04 +08:00 via iPhone

当然是前端处理，这有什么疑惑的？

thinkershare

2022-08-04 10:47:02 +08:00

@MrdotX 金额进度当然是后端处理, 不过一般不会设计到精度, 因为我们总是使用比分还要小 2 个数量级的单位, 根本就不使用小数存储金额, 而是直接使用 long

huiyadanli

2022-08-04 10:48:16 +08:00

金额精度后端处理
金额展示前端处理

aijam

2022-08-04 10:48:33 +08:00

https://stackoverflow.com/questions/2901102/how-to-print-a-number-with-commas-as-thousands-separators-in-javascript

Cu635

2022-08-04 10:49:33 +08:00

“我偏向前端只做交互和渲染，不做数据处理”

说的对，千分位就是数据显示问题，可以说是“渲染”，而实际的数据完全是不涉及的，所以 lz 问题的回答就是“应该前端处理”。类似的还有小数点是用逗号还是圆点，小数部分是不是要缩小一个字号这种问题。
lz 可以这么想一下：如果数据不再用逗号做千分位了，而是用空格，那么数据是不是就变化了？是不是 1 000!=1,000 ？

lingxiaoli

2022-08-04 10:51:02 +08:00

@MrdotX #7 你说的精度是指分? 后端存的时候就是按分存的给前端的时候前端按 ui 以及业务要求来做相应处理

ecloud

2022-08-04 10:51:56 +08:00

@Cu635 德国的小数点跟逗号就是反着用的，这本质上叫做 localization

Jooooooooo

2022-08-04 10:52:00 +08:00

后端做的好处是, 能更灵活的去调整这个展示的样式.

前端只单纯展示一个字符串.

damai0419

2022-08-04 10:54:41 +08:00

这种偏向前端处理。
像金额类的，后端基本要保存为币种的最小单位。
这串数字反给前端，前端怎么展示，很可能不同的终端不一样。￥ 1 ，000 ；一千元；壹仟元； 1000 元等等的。

ecloud

2022-08-04 10:54:42 +08:00

@MrdotX 精度问题，最好让后端改成用 long 存储，然后再给你返回一个 point （小数位）。比如 (1234567|point=3) => 1234.567 （分隔符取决于 locale ）

wangtian2020

2022-08-04 10:56:42 +08:00

后端提供原始数据，前端负责格式化显示
如果仅做一处数据的显示，也能后端提供

Routeros

2022-08-04 10:57:01 +08:00

我赞成前端做

MrdotX

2022-08-04 10:58:27 +08:00

Fine.. 领导说要前端做。。

MrdotX

2022-08-04 10:58:36 +08:00

沉了沉了

GeorgeGalway

2022-08-04 11:00:07 +08:00

我们前端是个美丽的小姐姐，所以当然是我大后端处理

fzdwx

2022-08-04 11:02:02 +08:00

@Jooooooooo #18

`后端做的好处是，能更灵活的去调整这个展示的样式`

不是应该是前端做，才更灵活吗？后端都直接把需要渲染好的数据返回了，怎么会是灵活的？

wccc

2022-08-04 11:03:56 +08:00

如果是美丽小姐姐,那就我来

wccc

2022-08-04 11:05:09 +08:00

前端修改比较合适,毕竟只是格式处理

Jooooooooo

2022-08-04 11:07:41 +08:00

@fzdwx 如果是客户端, 你还得发版等着用户去用户商店更新才能生效. 咋会更灵活.

fzdwx

2022-08-04 11:45:43 +08:00

@Jooooooooo

客户端这种场景，我确实接触的比较少。。。

fkdtz

2022-08-04 12:08:13 +08:00

OP 身为一名前端，此时正在处理

28Sv0ngQfIE7Yloe

2022-08-04 12:11:49 +08:00

@Jooooooooo #18

现在前端格式化库我觉得比后端灵活多了吧

otakustay

2022-08-04 12:18:26 +08:00

金额加逗号显然是渲染的事，你作为前端就算只做交互和渲染，也应该把这事做了

Jooooooooo

2022-08-04 12:42:29 +08:00

@Morii 我说的灵活是指更新的灵活, 不是实现上的灵活, 具体的逻辑看下 29l

28Sv0ngQfIE7Yloe

2022-08-04 12:50:06 +08:00

@Jooooooooo #34

soga ，我一直考虑的是 web 端，如果是客户端的话，我赞同

arch9999

2022-08-04 13:05:56 +08:00

@Morii

什么端，这个都是前端做。

hayvane

2022-08-04 13:12:55 +08:00

前端处理,另外 [我偏向前端只做交互和渲染，不做数据处理] ，其实，在实际工作中，有时候前端也是要做数据处理的
我也是前端（ app+小程序)

yaphets666

2022-08-04 13:45:37 +08:00

写个处理函数就行,咱是按天算钱的,不计件,多干点活没事,只要不加班就行.

cnoder

2022-08-04 14:56:51 +08:00

理论上输入和输出格式要一致，你觉得你给后端金额的时候会传 100,454.21 这种数据吗

fernandoxu

2022-08-04 16:09:57 +08:00

Intl.NumberFormat

janda

2022-08-04 16:33:52 +08:00

金额计算 - 后端
金额显示 - 前端

h1104350235

2022-08-04 16:35:50 +08:00

显示问题，一般是前端处理。
像这个数据结构的话，我一般会抽出个方法处理。

phobal

2022-08-04 18:00:51 +08:00 via iPhone

一行代码的事儿 Number.prototype.toLocaleString()

adjusted

2022-08-04 18:33:20 +08:00

后端，前端多个平台所有人都得改一遍

kkfnui

2022-08-04 19:02:09 +08:00

https://github.com/d3/d3-format

zjuster

2022-08-04 19:38:45 +08:00

前端处理。
用实际例子说一下，德国等国家的的千分号单位是“.”或者空格，小数是“,”。
德国 123 456 479, 00 或者 123.456.789,00
我国 123,456,789.00
为了适应当地的习惯和策略，前端展示上不同，但对账的时候的数值大小是一致的。

所以前端做展示，后端提供统一的财务数据比较合适。

zhuweiyou

2022-08-04 20:58:55 +08:00

前端处理,因为金额可能会做计算,比如*数量=总价,你后端返回带逗号的,你怎么做计算?

godblessumilk

2022-08-05 11:58:57 +08:00

必须是前端处理。因为你的系统以后可能会拓展到全世界，到时候有的用户用美元、有的用户用欧元做单位，你让后端全给你算一次吗？还有，关于时间的显示，一律让后端只返回时间戳，不可以返回处理好了格式的日期，因为你永远不知道你的前端用户在哪个时区

Cu635

2022-08-08 22:52:42 +08:00

@ecloud #17
说的对对，只不过我个人很不喜欢这种不统一又没有实际意义的人为差别，所以宁可跟着 lz 用“渲染”这个关键字。

@GeorgeGalway #25
既然是美丽的小姐姐是前端，不更应该让前端处理么，遇到问题了可以上去交流啊。