@fyxtc 好吧，，，看来解决了

@fyxtc komga 怎么可能无法打开 zip 。。。

试了一下，干，怎么 alphine 下的 sh 又显示当前目录了。难道记差了

问题的次要原因还在 alpine 默认只有 sh ，而 sh 不像 bash ，zsh 那样显示目前在哪个目录。
在 alpine 里操作的时候经常就出现不用 pwd 搞不清自己在哪个目录的情况。

极其经典的 EAV 模型问题。本质上产生这个问题的原因是想用 RDS 来实现 NoSQL 的功能。mysql 后来添加了 json 字段就是为了解决这个问题

https://juejin.cn/post/6997230227868876830
https://zhuanlan.zhihu.com/p/404294076

我的项目实践经验就是，用 join 是最好的方法。如果你是 mysql 新版本之类的也可以改数据库结构，直接定义个 json 字段把商品信息的 json 存进去倒也行（反正已经这样定义数据了，你查询速度怎么都快不了了）。最好最彻底的解决办法就是上 NoSQL 或基于文档的数据库，如 mongodb ，elasticsearch 之类的

想了会，lz 意思就是本地不同目录放了一堆不同静态网站，然后域名解析到本地，想通过 nginx 根据不同域名访问不同静态网站？

如果你这些静态网站都在 home 目录的不同地方的话，这情况你直接把 home 目录给 mount 到 nginx 容器里就行了。反正只是本地开发测试，怎么简单怎么来

@snylonue 是不是难以理解？我作为发帖者看了这么多回复，也难以理解为什么那么多人不厌其烦地说是验证问题。我只能说，这个帖子下说是验证问题的，基本全都是想都没想过纸上谈兵的人（而且往往这么说的人口气真的令人不适，所以才一个个怼过去）

@gogogo1203 emmmm 。。。。你怎么就这么被我说说就破防了。。。。莫非真被我说中了。。。。。

我连续两天对线不正好证明我工作量不饱和么。如果我信了 ls 那几位把所有字段都改成指针的提案，我怕不是要多加班一个月哦，哪有这闲心在这和别人对线。
“别人用 go 写 curd 都写了多久了” 不要觉得没人遇到过这类问题，仔细看看这个帖子，已经有很多人提到过遇到过这问题了，以及为了避免这个问题他们用了什么方法了，他们才是真的用 go 写业务有经验的。而这个帖子下回复的很多人（包括你），从回复来看，我深刻怀疑充其量就是用 go 写过小工具，或者只写过规模非常小的项目。用 Go 写实际项目和业务经验之少令人汗颜

其他不说，已经快 200 楼了，就在你上一次回复我的这短短几层之间，又有一位爷跳出来一副高高在上教育别人的口吻在说这是要加 validation 来解决的问题。请问这么多人真的有哪怕动过脑子想过这个问题么？

@kiwi95 chatgpt 这个做法我是知道的，但也和上面说全改成指针一样属于目前不太可行的方案。主要几个项目，json 解析相关的 struct 上百个，涉及到字段上千个。没办法简单批量将这些字段全替换成 NullableInt 、NullbaleString 之类的。其次即便想办法批量替换了，所有用到这些字段的代码因为字段类型改变了，全都要重写。对现有项目做如此庞大的更改是真的不太现实（当然新项目可以这么做）

@Terminl 请勿抓住所谓订单、价格不放，随便举个例子罢了，建议你看一下 139L

@ding2dong 你说的很好，没错, null 对应 go 的 nil ，而在 go 中要给 int 类型赋 nil 值是会报错的。所以按照你说的意思，将 nil 解析到 int 字段报错不应该是最符合直觉的行为吗？

@leochenL 21L 其实就说了，直接复制出 json 包改了判断部分
https://cs.opensource.google/go/go/+/master:src/encoding/json/decode.go;l=885
这一行是解析 null 的部分，内部的 switch v.Kind() 就是在判断解析对象字段的类型。目标字段为非指针、map 这些不可设置 nil 的类型直接报错就行了

前后就花了不到十来分钟，然后写了单元测试后全局替换掉包引用，扔到开发环境慢慢等测试开始摸鱼了。所以才有这么多时间在这贴里和人对线。等啥时候高兴了再加个 flag 用于开关这个特性会更好点。不过目前这严格解析已经够用了。
唯一的问题就是因为复制的 Go 1.21 的 json 包，今后 go 升版本的时候标准包有变化的话得跟上（不过问题应该不大，大不了把这个包搞成公司内通用 repo ）

@gogogo1203 这个帖子最初就一个目的：问怎么解决 null 解析问题，然后这个问题在前 20L 前已经被解决了。

但接下来我要说的话就不客气了

但是你要不要仔细想想猜为什么后来会发展为吐槽？因为我是真的被回复中的几位整烦了。
这个帖子 20 多楼之后除了少数几个回答可以看出真的有经验，回答是有用的之外，是不是一大堆自以为是、好为人师人的人一副教育人的口吻在提方案？提的方案还暴露了他们根本就在这方面毫无经验这回事。我就问，这贴已经有多少人说 null 解析是 validation 的问题？而这些说 validation 的人有多少人是能想到 null 解析是根本无法靠 validation 解决的？还出现了好几位“测试干什么”的主。更有说让人把一切字段定义成指针这么离谱方案的，最后被我拿例子怼眼前说在项目中用指针不现实反倒没下文了。

再比如说你，你自己扪心自问，你在 29L 和 35L 代码是不是展示了你最开始甚至连 json 解析 null 会出问题都没注意到？也不知道 null 解析成 0 会导致无法 validation ？我来猜一猜，你是不是被我指出有问题之后为了反驳我才去仔细读了 json 官方文档，才第一次知道 json 解析 null 值会有”我们认为 null 经常代表空所以跳过赋值”这一特性？
就好像上面好几位都在说“int 不是指针所以遇到 null 赋值 0 是合理的”一样，说这话就证明根本不知道是怎么回事硬要来教育人是不是？
PS：你再仔细看看我顶楼里的怎么说的 “尤其非指针类型字段，我下意识认为遇到 null 是会直接报错的，结果直接是当作不存在(undefined)来处理。。。”仔细想想

@lujiaxing 别逼逼
1. "请问你能教教我 json 这种 null 解析逻辑我该怎么做合法性校验呢" 静听高论，希望你能提出切实有效的方案而不是在这纸上谈兵。这个问题我自己已经解决了，只是像听听你会有什么更好的解决办法
2. 冷知识，实际项目中，外部接口可不光团队内部接口，还可能包括很多质量参差不齐对接的第三方非本公司服务的接口哦
3. 你是这个帖子第三个还是第四个动不动就问”测试干嘛去了”的人了。现实世界中测试不可能覆盖掉所有情况，总有纰漏，即便花费大心思去思考各种边界条件总归会出纰漏，对于复杂业务你想破脑袋现实都会给你一巴掌。而一有纰漏就质问“测试干嘛去了”的人，我觉得嘴脸十分丑恶
4. 我只问你一个问题你同不同意“后端不应相信前端/外部接口传来的数据”这一准则。如果你同意，无论你的团队编程质量多高，你就应该以最坏情况去写代码，你死鸭子嘴硬说永远不可能传 null 不校验那就是你自己都不遵守这一准则，把安全性的一切交给外部接口

@pkoukk so ，这和你搞双标有哪怕任何一点关系吗？
ps：解决办法 21L 就说了已经找到方向了。json 包魔改了一下加了一句判断工作良好已经用到项目里去了。这贴之所拉这么长，是真的太多人的回复（包括你）过于离谱了。就比如这个帖子里所有说这 null 解析是 validation 问题的，明显就试都没试过就一副很懂得样子教育人是 validation （ json 包这个特性实际上根本就没法做 validation ）。再比指针，我 2L 就说过为什么不现实了，你硬是要教育人强行说它现实一样

@lolizeppelin 你别说，在踩到 null 这个坑之前可能真的挺多人都注意不到这个问题。而且你说的怎么感觉好反思怪啊。学语言总有没有注意到或记住的细节，出问题或者被人指出来前是很难发现的。约定好非 null 但传了 null ，属于不太常发生的事情，所以才很久没出问题。但墨菲定律就是这么发生了，出了事故了

@pkoukk 你做人怎么能这么双标呢？自己提出所有字段定义成指针，然后被我指出倒腾指针反人类后就提出让我再多写一层 struct 转换过去，在业务层倒腾 struct 。结果我的项目就是这么做的却反过头来说这是臃肿抽象？ ps：我不会写 java 谢谢，我和 java 关系最近的也就是曾经学过一小会 kotlin ，仅此而已。项目分层无关语言是几乎所有复杂点的业务写到后来都会自然而然分的。我很喜欢 Go ，但对于像你这样动不动就让人在自己身上找问题，攻击其他语言的 Go 的小部分拥趸，真的很令人不适

@lujiaxing
1. 你和 ls 几位一样，我只是随便举个价格的例子而已你就只抓表象问题说事，遇到的业务问题不是价格也不是订单，只是订单更加容易理解
2. 我从来说的都是前端/外部接口解析的问题，请注意后者“外部接口”。你真的以为“金额/SKU 摘要/标题等是要你从订单里翻出来的!!”不会遇到 null 解析问题？假设你有订单 id ，然后订单详情需要请求另一个微服务 API 获取，这个 API 以 json 形式返回订单详情。好了，问题来了，这个微服务出了 bug 原本约定好禁止返回 null 的订单的金额、数量返回了 null 。请问你如何应对？请问你不还是遇到了同样的问题？这个问题不光是前段的，只要涉及到外部接口和 json 就会遇到

还有，请问你能教教我 json 这种 null 解析逻辑我该怎么做合法性校验呢？

@lujiaxing
@sylxjtu
内啥，莫纠结未知字段、未设置字段。这个帖子争论的重点还是在 null 的解析上。

@maggch97 说得很对，实际做了这么多项目后的感叹就是，实际复杂点的业务项目要考虑的问题太多了。光是一个外部交互检查有问题，或者业务逻辑层考虑不周全就很可能导致后面业务流程出大问题。虽然业务代码已经进最大努力将所有能想到的情况都检查了，但实际项目运行中依旧会时不时出现一个完全意想不到 case 导致出问题。

@pkoukk 我觉得包括你在内，很多人都有个问题，问的时候都一个个口口声声说后端不能信任前端/外部接口传来的数据，实际真的干起活来怎么就觉得不用遵循这一基本要求了呢？ API 文档约定是一回事，实际过来什么数据只有天知道。作为后端肯定要以所有字段都可能被瞎传入 null 为前提考虑问题，遇到约定不能传 null 的字段传 null 了就报错，这难道不是后端的基本素养和常识？

其次，不好意思，作为用 Go 参与了 N 个复杂业务项目的表示，请求从 DTO 进来、转成 Entity 处理业务逻辑，最后在 repository 层里转成 model/DO 是我写项目的基本要求。但问题来了，json 解析不光出现在 DTO ，我请求外部接口也要解析 josn 哦。你说的全部定义成指针，那么这意味我一切 API 的一切 DTO 字段，所有请求外部接口解析结果获得的字段都要定义成指针，当然转成 entity 后业务层是不用太在乎，但我只能说，哦，真的太优雅了，工作量真的是太不饱和了。而且，即便是 DTO 层和外部接口请求也多少会有点和业务无关的逻辑的，让你对这些指针倒来倒去是真的不切实际的提案。哦，你说在 DTO 和 Entity 之间在加一层 struct 专门用来处理 DTO 层的部分逻辑？哦，见到这样写的代码大概率我会拒绝 review 的，因为照你这样搞这个项目 DTO 层漫天飞舞的指针就是今后屎山的起点