背景
前一段时间做了一个业务上的修改，(以下均为举例) 原始在violatangxl.github.io下有个名为XXX_id的 cookie （生成机制，简单理解成一个带有时间戳的字段吧，每次生成结果都不一致），因为某些原因，想把该 cookie 的 domain 扩大到 github.io。
简单想着，嗨，就是一个把 cookie 的 domain 扩大的情况，应该不会有什么问题。结果run 起来发现一个“意料之中”的情况: 因为之前的 cookie 没有清，导致不同域名下，有两个相同的名称的 cookie。因为不同的后端服务，读取到的 XXX_id 不同，导致线上崩了。
思考
抛开没有清旧 cookie 的问题，借着这次的情况，来重新整理一下有关 cookie 的知识点：
- name:
cookie的名称，cookie一旦创建，名称就不能改 - value:
cookie的值 - maxAge:
cookie失效的时间，单位秒。如果为正数，则该cookie在maxAge秒之后失效。
如果为负数，该cookie为临时cookie，关闭浏览器即失效，浏览器也不会以任何形式保存该cookie。
如果为0，表示删除该cookie。
默认为-1。 - secure:
该cookie是否仅被使用安全协议传输。安全协议。安全协议有HTTPS，SSL等，在网络上传输数据之前先将数据加密。默认为false - path:
cookie的使用路径。如果设置为/test/，则只有contextPath为/test的程序可以访问该cookie。
如果设置为/，则本域名下contextPath都可以访问该cookie。注意最后一个字符必须为/。 - domain:
可以访问该cookie的域名。如果设置为.github.io，则所有以github.io结尾的域名都可以访问该cookie。注意第一个字符必须为.。
常用的几个属性，就在这里了，重新复习一下，之前还写过一篇讲httponly 与 secure的短文
问题与收获
回归主题，上面说出现了两个同名不同domain下的cookie，然后不同的后端服务，读取cookie的顺序又不同，导致出现了 bug。
通过这次事故，这里有几个小点需要备注一下：
- 不同
domain下，同名的cookie，后端都会收到，不会说有什么domain的优先级，导致后端只收到“优先级高”的一个。 - 后端取到的，只有
cookie的name与value，所以拍脑袋想通过domain过滤出需要的cookie是不可取的 - 参考一下RFC6265 HTTP State Management Mechanism 传递到后端的
cookie顺序不一定。（原文意思是后端不应该依赖cookie的顺序） - 但在 chrome 测试，发现后端收到
cookie还是有一个稳定的顺序的：path更长的cookie更靠前，path相等的，更早创建的cookie更靠前
