LuffyPro 最近的时间轴更新
LuffyPro

LuffyPro

V2EX 第 669338 号会员,加入于 2024-01-02 13:53:30 +08:00
LuffyPro 最近回复了
@hemingway 裁判文书网,应该只能查到被执行的了,没结案应该查不到。
不大相信,大厂会出现这种低级错误(当然,也有可能是我视野不够,触及不到这种 bug 出现的其他场景);不过就看到几个截图,不知道是否必现,如果是必现问题,这锅放到产研线,谁的锅更大点?程序员?测试?
53 天前
回复了 david101 创建的主题 问与答 如何培养父母浪费的好习惯?
老一辈一般比较固执,但也比较相信权威,虽然很无奈,但有些话换个人说出口,别人可能就信了。换种方式让一些有权威性的人告诉他们:

1.比如约个医生朋友到家或者某天去医院了,让医生跟他们说,不好的饮食习惯容易引发疾病,看一次病要花不少钱。

2.看看网上能否找到有关类似“长期吃剩菜会影响健康”的官方媒体报道,下载放电视上,给父母们看看。
170 天前
回复了 LuffyPro 创建的主题 程序员 前端校验还是后端校验的问题
谢谢大家的回复,我看了下,大家好像都集中与前后端校验上,可能我问的方式不对。

我的本意是,前端表单项中,没有发送数据变动的表单项数据有没有必要在编辑时也一起提交上来,打个比方,一个表单中有手机号码和名字,这时候只改了名字,手机号码没改,在提交时,有没有必要把没发生变化的手机号码也一起通过接口提交上来。

因为如果没变化的手机号码也提交上来,并且手机号码必须确保唯一性,后端在校验号码唯一性时,除了判断手机号码是否已经被注册,还得再判断一遍是否等于当前用户的手机号码( true 的话支持继续修改),后面这个是否等于自己的手机号码的判断是因为前端把没有变化的手机号码也提交上来的,如果约定,数据不发生变化时不需要提交,那后端就只要判断该手机号码是否被注册就行了。

感觉 15 楼明白我在说什么。 @old9
171 天前
回复了 LuffyPro 创建的主题 程序员 前端校验还是后端校验的问题
@rabbbit 嗯嗯,不过这个判断交给后端去判断感觉也怪怪的,相当于把这个数据是否变化的判断交给后端去做了。当然你列举里面的很多字段是不需要判断数据是否发生变化的,因为没有手机号码有特殊的唯一性要求,其他数据提交上来直接覆盖就行了。
171 天前
回复了 LuffyPro 创建的主题 程序员 前端校验还是后端校验的问题
@LuffyPro 不传上来,后端当作你不想改手机号码,传上来表示你想改手机号码。
171 天前
回复了 LuffyPro 创建的主题 程序员 前端校验还是后端校验的问题
@facebook47 @IDAEngine @InDom @lneoi @Removable @rabbbit 谢谢大家回复
当然这里后端是要校验数据的,但我的意思不是后端不做校验,而是有没有必要特殊处理这种数据没变化但又把数据提交上来的场景,比如上面例子说的手机号码,手机号码是唯一的,如果你传过来的手机号码,数据库中已经存在了,后端就不给提交,但现在后端需要校验多一次传过来的手机号码是否等于他自己的手机号码,如果是这种特殊情况,能让他提交。如果前端校验该表单项没发生数据变化不提交上来,后端就不需要做这层校验了,接口传上来的手机号默认都是当作想要修改的。不过这样前端需要提交前判断相关表单项,而且不大可能每个表单项都去做这种数据无变化的判断,来决定要不要将手机号码传给接口。
@matrix1010 @yinmin @maymay5 谢谢回复,这几天忙其他的,后面看看大家说的这些方案。
谢谢大家的回复!
@renmu 谢谢建议,回头我试一下。
@Trinityuan 嗯嗯,你的补充是我现有方案正在执行当中的优化版。
@vacuitym 提示语里面确实没提供实例,返回格式这点是有规范要求的,我尝试过,数量不等时,带上上下文,同时强化提示语,结果返回还是数组长度不一致的结果。
@matrix1010 嗯嗯,目前暂时是这么做的,然而,这样会有两问题😂:
1.调用次数增加,耗时增多,延迟加大,用户体验不好;
2.增加 token 消耗量。
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1896 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 29ms · UTC 16:26 · PVG 00:26 · LAX 08:26 · JFK 11:26
Developed with CodeLauncher
♥ Do have faith in what you're doing.