Django 提供了几个内置的信号，允许在不同事件发生时执行特定的代码。这些信号主要用于模型、请求/响应处理以及数据库操作。以下是Django中常用的信号分类和具体信号： 1. 模型信号这些信号与Django模型相关联，用于在模型的创建、保存、删除等操作时触发。 pre_save：在模型的save方法被调用之前发送。 post_save：在模型的save方法被调用之后发送。 pre_d

客户端1cat ~/.ssh/id_rsa.pub 服务端12vim ~/.ssh/authorized_keyssystemctl restart sshd

对于正常执行的前台程序，可以使用ctrl + z，让程序停止，然后通过bg %job_id 把程序放入后台运行 12345678910111213[root@luffy study]# bash sleep500S.sh ^Z[1]+ 已停止 bash sleep500S.sh[root@luffy study]# jobs[1]+ 已停止

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849[root@luffy luffy2]# cp --help用法：cp [选项]... [-T] 源文件 目标文件　或：cp [选项]... 源文件... 目录　或：cp [选项]... -t 目录 源文件...Copy

任何装置在 Linux 底下都是文件 文件种类到使用『ls -l』观察到第一栏那十个字符中，第一个字符为文件的类型。除了常见的一般文件(-)与目录文件(d)之外。 正规文件(regular file )： 是一般我们在进行存取的类型的文件，在由 ls -al 所显示出来的属性方面，第一个字符为 [ - ]，例如 [-rwxrwxrwx ]。另外，依照文件的内容，又大略可以分为： a. 纯文本

python性能调试过程中最突出的问题就是耗时，性能测试工具有很多，像profiler，cprofiler等等，都是只能返回函数整体的耗时，而line_profiler就能够很好解决这个问题 项目地址 https://github.com/rkern/line_profiler 这里记录 line_profiler 的两种用法 通过装饰器 @profile123456789101112131415

查看网关12345678[root@luffy ~]# route -nKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface0.0.0.0 10.67.9.253 0.0.0.0 UG 100 0

DRF整合了非常多的开发常用组件，认证，授权、限流等等，简单配置即可使用 认证和授权全局配置开启全局配置，只要请求后端接口，都需要进行认证才可以请求成功 settings.py 12345678910111213# DRF 组件配置REST\_FRAMEWORK = {# 内部循环遍历注册的认证类，一旦成功，结束循环'DEFAULT\_AUTHENTICATION\_CLASS

DRF封装了很多关于请求信息的参数，我们可以通过 request获取，响应 Response 也有着规定的模板，让接口响应更加规范。 在视图中，封装了非常多的视图类，便于简化视图层操作。 APIView是DRF中提供的所有视图类的积累，它继承于django.views.View，传入的请求是DRF的 Request实例，任何APIException异常都会被捕获，并且传递给合适的响应 ，业务代码

在返回json数据时，整合DRF后并没有取出QuerySet中的数据，再转字典，也能直接返回json，这就是序列化器的功劳。 序列化，序列化器会把模型对象转换成字典，经过response以后变成json字符串 反序列化,把客户端发送过来的数据,经过request以后变成字典,序列化器可以把字典转成模型 反序列化,完成数据校验功能 12345678class StudentModelSerial