重拾些许关于信号模块使用的记忆，记录对于 Django 信号使用的思考。本文使用的 Django 的版本是 4.21 源码注释 {代码...} 2 函数清单2.1 _make_id 方法 {代码...} 首先认真分析下其业务实现，target 参数是接收器（即普通的函数或者是 bound 方法）如果是普通的函数，则使用 id 函数获取 target 的唯一标识，返回的类型...

1 错误描述 在查询数据集中的日期时间对象时 {代码...} 然后报错 {代码...} 2 解决问题 实际情况，数据库中是有数据，目测月份提取失败；到 mysql 执行了下 {代码...} 果然，结果返回令人诧异的 NULL 看了下 Django orm 的 datetimes 官方文档 {代码...} 即 mysql 需要使用 mysql_tzinfo_to_sql 载入时区表，接着跳到 [...

其中对于限流和权限验证，都可以自定义类解决需求，重点还是在于数据检测，本着不能相信前端输入的数据的原则，要做好数据检测，也不是件轻而易举的事情，毕竟疯子的想法你是猜不透的。

在某些业务需求下，对于模型的某些字段，使用 JSONField 适配业务，但是这种字段在 django admin 下显示以及修改不是很直观和方便，所以这里动了念头，美化处理下 JSONField。

通过源码可以发现，每次请求进来，都要做认证，权限验证和限流验证。如果所有接口都需要权限，这直接在视图类中直接设置 permission_classes 即可；如果针对业务中部分接口需要权限，其他不需要权限的场景，这样一刀切的方式是行不通的，因为进来的请求会被权限打回去，针对部分接口需要权限的场景，可能需要变通一下。

在关联的模型中，比如多对一或者多对多这些类型，在某些场景下，比如简单快速为特定用户添加标签，为了快速添加对象，会使用反向添加，这里简单描述多对一场景下

模型字段中 UUIDField 类型小记 进来在一个小应用中使用了 UUIDField 字段类型，在视图写完跑单元测试时，发现获取的结果和我期望的不一致....。 1 使用 UUIDField {代码...} 所使用的 UUIDTools.uuid1_hex 代码如下： {代码...} 2 在终端中跑个测试 {代码...} 可以看到返回的 id 字段中有横岗，我查了数据库发现，数据...

有时候会碰到这样的场景，对于一些业务升级，我需要把数据库数据做些处理，同时又想以 Django 项目的环境变量执行脚本，这个时候使用 python 脚本是再适合不过的手段了。

当前产品开发，前端和后端完全分离，在调试阶段，静态服务器和接口服务器的端口是不同，前后端通信时，这里就需要跨域处理， 这点完全可以再后端进行处理。

在使用 django 开发中，不可避免的总会遇到静态文件的处理，特别对于前端来说，页面的调试都是依赖静态文件（JS，CSS，Image等等），Django 在静态文件处理这一块做的不错，但不是最优秀，毕竟 Django 只是一个框架而已，更多的业务需要搭配其他工具共同完成，这是后话。

通常我们熟悉使用的都是 pip, 这个工具确实方便项目管理依赖包。当想把当前项目依赖的包的名称和版本导入指定的 txt 文件中时，只需要执行

一般我们在练习 django 渲染时，都需要使用 context 来解析渲染模板。 通常，context 是 django.template.Context 的实例，不过在 context 中还有一个特殊的子类， django.template.RequestContext ，这个和 context 稍微有些不同。 RequestContext 默认地在模板 context 中添加一些变量

测试生产服务器中，设置 DEBUG = False，这种情况下 ALLOWED_HOSTS = [] 就会开始起作用，如果设置为空，就是看到的 400，所以这里需要修改允许的 HOST

在做应用时，考虑到应用的会产生很多图片，为了省劲，就选择了七牛云存储，使用云存储的好处大家都是有感的，但还是有一点点担心，如果使用的第三方云存储挂掉了，(=@__@=)，这是后话

模板|自定义 context_processors Django 版本 1.6.7 原因 因为当前模块下的所有视图都需要共同变量，就想到了利用模板系统的自定义 context_processors 目的 偷懒，降低工作量，重用 准备 {代码...} 步骤 1 自定义函数 {代码...} 自定义函数（测试随写的） {代码...} 2 视图逻辑 {代码...} 3 TEMPLATE_CONTEXT_PROCESSOR...