56 lines
2.1 KiB
Go
56 lines
2.1 KiB
Go
|
package service
|
|||
|
|
|
|||
|
|
import (
|
|||
|
|
"encoding/json"
|
|||
|
|
"fmt"
|
|||
|
|
)
|
|||
|
|
|
|||
|
|
// OptionKey 把一个规格组合变成**稳定的字符串标识**。
|
|||
|
|
//
|
|||
|
|
// {"size":"M","color":"黑色"} -> {"color":"黑色","size":"M"}
|
|||
|
|
// {"color":"黑色","size":"M"} -> {"color":"黑色","size":"M"} （同一个结果）
|
|||
|
|
//
|
|||
|
|
// # 为什么需要它
|
|||
|
|
//
|
|||
|
|
// 采集回来的 PDD 数据里**没有 SKU 编号**，一个规格只能靠它的
|
|||
|
|
// options 组合来认。而 JSON 对象的键是无序的：
|
|||
|
|
//
|
|||
|
|
// 存映射时：{"color":"黑色","size":"M"}
|
|||
|
|
// 采回来时：{"size":"M","color":"黑色"}
|
|||
|
|
//
|
|||
|
|
// 这两个是同一个规格，但字符串不相等。直接比原始 JSON 会匹配不上，
|
|||
|
|
// 而且是**静默失效**——不报错，只是查不到，最后表现为"明明匹配过却说待匹配"。
|
|||
|
|
//
|
|||
|
|
// # 为什么只能有这一处实现
|
|||
|
|
//
|
|||
|
|
// 存映射用它算 key，查规格也用它算 key，两边必须**逐字节一致**。
|
|||
|
|
// 如果 Client 那边也算一份、或者别处再写一个"差不多"的版本，
|
|||
|
|
// 只要有一点点不同（空格、转义、键序），映射就会静默对不上。
|
|||
|
|
// 所以：**Client 只上报 options 对象，key 一律由 Admin 这一个函数算。**
|
|||
|
|
//
|
|||
|
|
// 实现上直接用 json.Marshal —— Go 序列化 map 时会**按键名排序**，
|
|||
|
|
// 这正好就是我们要的规范化，不用自己拼字符串（自己拼容易漏掉
|
|||
|
|
// 值里含分隔符、含引号之类的边界情况）。
|
|||
|
|
func OptionKey(options map[string]string) (string, error) {
|
|||
|
|
if len(options) == 0 {
|
|||
|
|
return "", fmt.Errorf("规格组合不能为空")
|
|||
|
|
}
|
|||
|
|
buf, err := json.Marshal(options)
|
|||
|
|
if err != nil {
|
|||
|
|
return "", fmt.Errorf("规格组合无法序列化: %w", err)
|
|||
|
|
}
|
|||
|
|
return string(buf), nil
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
// OptionKeyFromJSON 从原始 options JSON 算出 key。
|
|||
|
|
//
|
|||
|
|
// 用于处理采集回来的数据：先解析成 map，再走 OptionKey，
|
|||
|
|
// 这样键序、空格、缩进的差异都会被抹平。
|
|||
|
|
func OptionKeyFromJSON(raw string) (string, error) {
|
|||
|
|
var options map[string]string
|
|||
|
|
if err := json.Unmarshal([]byte(raw), &options); err != nil {
|
|||
|
|
return "", fmt.Errorf("options 不是合法的字符串对象: %w", err)
|
|||
|
|
}
|
|||
|
|
return OptionKey(options)
|
|||
|
|
}
|