前端同事总是问我要 form 表单的枚举，多个我能理解，为什么性别和有些 3-5 个字段的类型也要返回呢。这些接口数量多了不是增加服务端压力，并且会阻塞后面的请求吗？
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 2198 days ago, the information mentioned may be changed or developed.
 |
null113Nov 6, 2020
1
让他们写个静态的 json
|
 |
geebosNov 6, 2020
2
免得后面枚举变了还要改代码吧，谁知道后端会用什么奇葩的枚举值
|
 |
lowerNov 6, 2020
3
搞个字典表，一个接口搞定，上缓存
|
 |
QcuiNov 6, 2020
4
性别之类不会变的枚举可以前端固定，其它的还是老实给接口吧，谁知道后面会怎么变。
|
 |
zarteNov 6, 2020
5
考虑太多呗，自己建站的时候就会能省则省了。
|
 |
CurtionNov 6, 2020
6
这个看业务吧，和数量无关；性别的话讲道理不需要接口
|
 |
zoharSoulNov 6, 2020
7
放 Apollo 上, 让前端自己拿去
|
 |
IvanLi127Nov 6, 2020 via Android
8
我只知道前端用接口查也挺折腾的
|
 |
zealinuxNov 6, 2020
9
其实性别也真需要接口返回的，
不过可以放在缓存里。 太多的教训了，前端写死是大忌。 |
 |
hb0730Nov 6, 2020
10
数据字典表
|
 |
kanezengNov 6, 2020
11
这玩意前端确实不要固定，谁也不知道以后怎么样不是。比如性别吧，最开始大家都是两个选项，后来有的就加了个保密什么的，发展到现在，你看 Facebook 就这个框有 56 个选项。但是你后端可以放缓存减少负担（然后个人觉得有些选项前端也可以一次性先从后端获取，然后缓存在 localstorage 之类的地方）。
|
 |
zm8m93Q1e5otOC69Nov 6, 2020 via Android
14
搞一个数据字典表，然后缓存在 redis 里，前端每次只要一次请求获取所有的字典
|
 |
nekochyanNov 7, 2020
15
我们是单独一个接口请求配置信息存本地，每次登陆 hash 一下不同就重新下发
|
 |
TomVistaNov 9, 2020
16
谷歌注册的性别选项告诉我们,人的性别可能发生变化🐶
|
Select Language