@siteshen 简单的说，就是你们少了一层抽象：API response 。加上之后 API 返回字段就只和 API response 层相关，不需要和 model 、logic 层耦合（甚至 model 用 ORM 实现、甚至存储换成 redis/mongodb 也不会影响前端）。

// models/user.go
struct User {
username string
password stirng
age int
...
}

// responses/user.go
struct UserResponse {
username string
age int
...
}

func NewUserResponse(user *User) {
...
}

// handlers/user.go
funct ReadUserHandler(req, res) {
user = models.ReadUserById(req.UserId)
return response.NewUserResponse(user)
}

建议明确前后端的界限，前端只是把后端当个黑盒子使用，做前端的只能「建议」后端怎么做（反之亦然）。

前端遇到问题，只需要告诉后端某个请求有问题，并提供 curl 命令、预期结果和实际结果。

至于后端是用断点、log 、买个啄木鸟还是拍电脑，都与前端无关。

没人关心这贴子和「竹板」有什么关系吗？

理解别人的代码确实很困难，因为这不止取决于看代码的人，还取决于写代码的人。

但要做到以后能理解自己的代码还是能做到的：
1. 尽量用最高的标准要求自己的代码；
2. 不那么明显的工具函数会有简单的测试；
3. 不得不 HACK 的代码会用注释写明原因。

不夸张的说，我现在还能较容易地看懂我三年前写的代码。

俺也一样

代码没什么问题，不过倒是 signature 的算法和一般的不一样。

一般是这种：
输入是： {"a": 123, "c": 292, "b": 299}
签名的字符串是：a=123&b=299&c=292

很少会要求 JSON 的 key 是「有序」的。这通常意味着要么依赖内置的排序（不同语言的排序方式可能不一样），要么手动对 JSON 的 key 排序（麻烦，某些语言甚至只能用拼接字符串的方式实现所谓的 JSON encode ）。

愁生于郁，解愁的方法在泄；郁由于静止，求泄的方法在动。
多打网球，多弹钢琴。实在不喜欢就谈谈笑笑，跑跑跳跳！

我谈不上热衷环保，也没什么想法， 不过有让世界变得更美好的愿景。
如果你们有些想法 /项目，我愿意作为参与者，提供一些技术上的支持。

和有话语权的同性长辈睡一张床。

602M

@belin520 关键是没办法关闭这类信息的推送，只好关闭支付宝所有的推送。

@janxin 可能真的有这种最佳实践，毕竟动态类型语言的优势在于 duck type，即使要判断也应该是判断参数是否实现对应的接口，而不是要求参数是指定的类型。

@ManjusakaL
1. 坚持用 python 2.x 的用户不是 type hint 的目标用户；
2. type hint 如果是程序员主动发起的话，肯定是会配置一些基础的检查的；
3. type hint 不是万能的，static analysis 比 no analysis 还是好了不少的，最不济还能当个注释，让 ide 能智能补全。

@shintendo 我疑心题主说的也是读书时候的「喝了雪碧一样的心情」。

成都自如，由于疫情的影响，短续两个月的价格和租期一年一样。南京那边也是这样的话，可以先续着，疫情结束后搬家也方便些。

在后端做的话，可以额外加个字段，API 调用时用原来值，展示时用 display_xxx 属性。

# model：
class Post:
category = models.CharField(max_length=100, choices=(...))


# API 设计：
{"category": "finance | art", "display_category": "财经 | 艺术"}

# 辅助函数，从 choices 里解析出对应的值：
def get_display_value(post, field='category'):
# model = post.__class__.model
# choices = ...
# [c[1] c for c in choices if c[0] === getattr(post, field')][0]


# 进一步优化的话，可以写个 decorator 完成转换工作：
@display_fields('category')
def list_post(request, response):
# 原来的逻辑

# 以上伪代码未考虑错误处理，请自行完善。

我们公司是做 AWS 迁移、运维、管理相关业务的，有需要的话可以了解一下。