首先是保存，先给step步骤表加上这个公共请求头的字段：
然后运行双命令：
现在我们有了这个存放公共请求头的字段了，那么就去前端的P_cases.html中找到保存步骤step的js函数，给它加上公共请求头吧：
添加完成之后。我们去到views.py中找到这个保存功能函数：
加上红框内俩句代码：
如果没有意外，那么现在应该保存成功了。我们可以重启服务刷新页面，测试一下：
保存了俩个请求头。
然后进入后台可以确认，的确保存成功了：
然后我们要做的是显示。
就是打开一个step详情页的时候，要显示上。我们上节做的是 切换接口仓库的接口需要显示，本节要做的是 打开/切换不同的step 要显示step自身的保存的公共请求头：
而这个过程是有俩部分的，1是要在初始化的时候让其全部清空，2是在根据请求返回值选中目标接口的请求头。
所以先来动clear初始化函数：
改完之后，我们刷新页面，打开刚刚的step,看看是不是确实选中了俩个请求头：
这个样子看起来，就是成功了。
但是这时候我们会发现一个问题：
问题描述：当我切换到一个旧step步骤的时候，会出现js报错。这个原因是因为，我们旧step的 公共请求头字段中，是个null。连空字符串都算不上，这种问题的避免方式就是我们之后新加字段时候 指定初始默认值。
不过现在 已经这样，我们的补救措施 有几种：
- 写个sql，跑批，把所有这种为null的全部变成""空字串。
- 手动去后台处理这种脏数据，数量不多的情况下。
- 在js代码中 加入补丁，给异常try掉。
4. 在js代码中 加入一个if判断，如果为null， 则转成空或不运行这个选中请求头代码。
我们简单一点，选4:
if判断只有在不为null的时候才会运行。
现在不报错也么问题了，而且当我们保存了一次这个step后，那么它就会变成正常状态了。
接下来就是我们要实际去在请求函数中加入这个公共请求头的事了：
在runcase.py中找到这个函数demo，先从数据里拿出这个步骤step的公共请求头，需要用split函数变成请求头的id组成的列表。
然后就是最复杂的header加入了，
我们先找到应该写这段代码的位置，也就是在我们正常header成功转变为字典后，进行加入。
不过为什么我说这里比较复杂呢？因为我们现在拿到的，仅仅是各个公共请求头的id ！想获取到真正的key和value，还需要去数据表中拿出来才行，我们上节在接口库的调试层中就是这么干的。
不过在这个run_case.py中，却行不通，因为这个文件，是游离在django项目之外的一个独立py文件，我们之前也仅仅是调用这个文件而已。这种文件的显著特点就是，你修改内容，项目不会自动触发重启，而你也不需要重启，运行就可以实现最新状态。
但是现在的麻烦问题是，既然文件是游离之外的，那么它目前是没有权限去直接从django的数据库中拿数据的。
那么目前我们的解决办法是有俩种：
- 仍然靠我们调用的时候 在函数层面 把这些请求头带过去。
考虑的点：
带过去的是多少请求头，调用的时候是整个大用例内的多个step步骤，每个step的请求头数量和内容是不同的，如果把每个step的请求头作为列表传输，那么可能会有浪费现象，比如 step1 用的请求头是A和B, step2用的请求头是B和C，那么我们传递的列表如果是这样[ [A,B] ,[B,C] ]，虽然可以达到效果，但是其中的B就重复传递了一次，造成了巨大浪费。
如果是把整个项目的公共请求头全传递过去，这样可以保证不会重复传递，也就是直接传递[A,B,C,D,E] ，然后step1和step2都去各取所需，这样虽然没有重复传递B，但是很明显，D和E浪费了。
当然也可以 提前写一个算法，求并集，只传递[A,B,C]。这个目前看是最优解。
2. 我们不传递，我们直接给这个游离文件 强行加入到django项目内，让其获得数据库权限，然后直接去查对应的请求头出来 即可。这样做的唯一缺点是，这个文件将失去灵活，以后改一下，都要等项目重启，才能生效了。这就是增加了高耦合的风险。
最终我决定选择第二种方案，因为第一种方案相信读者应该自己可以搞得定。第二种算是给大家讲一个新的知识点。
所以我们在run_case.py的开头加上这几句，来让其具有数据库权限。
然后下面我们加入请求头的代码如下：
我们打印了header最终，运行大用例，看看请求头是否成功加入进去了：
运行结果：
可以明显看到，在我们上面的输出中，那时候还没有加入公共请求头的header和下面已经加入公共请求头的header。看来是加入成功了。
最后我们就是改一改这个输出位置就完美了：
如上图，我把这段输出，移动到了加入公共请求头代码的下方，注意输出的不再是step的原始请求头，而是最终的header了，并且最前面加了个\n换行符，重启服务，再运行看看效果：
这样显示就正确了。
