@GTim 你说了半天我还是没懂，bigint 是如何存储时区信息的？ 转 UTC 时间的 timestamp ？

那么用 datetime 还是用 bigint 有差别吗？ 为了防止人肉眼看的时候能直接看出来这个是什么时间吗？

bigint 和 timestamp 最大的差距仅仅是 2038 的长度问题， 除此之外他们在存储本质上没区别，只是后一个 mysql 可以自动处理给你显示成人类可读的时间。

@GTim 可以存入数据库的时间都使用 UTC 时间，程序读取和写入的时候做转换。

@stroh
另外，我不确定其他回复的人里主要争吵的点是什么。

我回复的内容里，前两个大概在分析这个错误发生的原由，后面 5 、6 条其实都在针对一句话 “我也做过 xxx”。

做事的时候最讨厌这种不干这事的人出来放这种轻巧屁——贬低别人水平、职责别人忽悠蒙人。
被说中人都会被激怒何况是还没这歪心思的人呢。

之前有个产品给我们提需求就老是“这个很简单啊？怎么需要这么长时间？”，“我也学过 SQL 啊？不就是写个查询吗？”。
他特么一个需求要改 5 、6 个不同的接口，展示的那个属性的查询条件，在有的地方需要通过登录用户信息关联，有的需要物品信息关联，还有的需要通过关联关系找到多条数据再查。
他一句“不就写个 SQL 吗用得了这么久吗？”气得我们组长说“用不了那么久那你来写”。

一个多结构嵌套的页面，赶进度的时候让快点催得急，我们后端就自己写，我们从其他页面挪了一些类似的组件过来改吧改吧，上线后发现有个块整体歪了 1px ， 他去找我们我们说不会，得前端看看。
他找前端也是 “不就歪了 1px 吗？你移一下不就好了？”，前端也憋着没说话，后来找了半天找到上面有个空的元素外面看 hight：0 ，但内部有个不可见元素有体积给挤到下面了，导致后面好几块都乱了。

换你是我们这个前端， 听到产品说“我也懂前端，不就调一下 margin 吗” 你什么感觉？

@stroh 你我对于 http 访问链路的基本知识都不在一个水平
(我觉得前端现在都不需要了解什么是 httpserver 什么是反代真的是要求太低了...)，
加上屁股不一致，我和你无法达成共识的。

对于我而言，和你们那个后端一样，一看到访问的 url 起始前缀都不是我们后端项目地址，一瞬间就知道与后端无关了。
然后自然就可以推导出两种结论，要么网关路由有问题，要么你们前端打包有问题，包括丢页、包括 URL 拼接变量 bug 。

接下来就是屁股问题，既然我是个后端，找我看问题，那我确认问题不是我这那就是完事了，我对前端和运维一知半解难道还要我去一路 debug 吗？

至于说积怨已久这个只能说非常常见，避免不了，工作有接触自然会有摩擦，所以你有怨气，我带入你们后端视角更有怨气。

@xinple 说前端的错误是说，他沟通阴阳怪气，而且自以为是把不是别人的问题按到人头上 “我写过后端 500 就是后端错误”。

换个生活中的例子。

假如你是卖电脑的， 客户发现上不了网了，给小区的联通的服务商打电话，然后这个搞网的是个二把刀，一看客户网线灯能亮，“不是我的问题，灯亮了说明线好好的，应该是你电脑问题，你找卖电脑的吧”。
然后把你叫过去你一看这和我有 p 关系啊？　然后打电话给百度把他骂了一顿，说肯定就是他们的问题，水平真菜。
虽然这事和人家也没关系，但人家大概一看是什么 dns 无法解析，就大概知道是网的问题，和你说让你找修网的，结果你张嘴就是 我也做过软件，这肯定就是你们的毛病，还最大的中文搜索引擎呢。
然后网上发帖，“百度原来就这水平啊？ 挣钱好容易啊”。

这件事技术上的本质是什么？ 负责网络链路的货是个二把刀，自己瞎逼甩锅。

但这个帖子的问题是什么？ 自己一知半解却以为自己最他么懂，别人告诉你正确结论了你还以为自己是对的，说话阴阳怪气不为解决问题就是为了甩锅和发泄不满。

---------------------------

你告诉我这个前端没错？ 运维甩锅给他他有火气，那他瞎甩锅给后端没火气？他一路阴阳怪气 人家还好好在告诉他是谁的问题。

这还是个后端领导，要我绝对把对话甩给他们前端领导，让他们前端领导看看这个“说话的艺术”，然后自己查问题去。

即便我是大头兵那也会直接说，“来，这回我带着你挨个把这条链路都厘清楚，让你看看到底谁的问题，如果是我的问题，从此以后，你找我什么问题我都给你解决不论是谁的，如果不是我问题，以后找我看问题请自己带上前端日志，还有网关 access 记录，最好后端日志你也找出来，我可以去找领导给你开日志查看权限。”

@wonderfulcxm
那是因为 php 和 nginx 的结合方式是用 cgi-bin, 原理上和 允许 lua 类似，属于于 nginx + 插件这种方式，nginx 和你的脚本绑定到一块了，属于 nginx 作为执行者去调用了某个函数然后访问了你的脚本，属于同一个进程内的方法调用，然后函数去返回某个结果，调用出错 nginx 作为调用方是会接收到异常退出信息的。

然而这种题主的截图对话里告诉你了人家后端是 java 开发，java 不玩 cgi-bin 。


实际上 cgi-bin 的优点是非常简单方便，但缺点限制更明显，以前的脚本语言支持这种协议的多一些，php, py, perl 。

但其他大多数语言不论是 java ，go ，.net 还是 nodejs ，甚至你们 php 的许多框架也都直接选择了用自己实现的 http-server 来执行对应的代码，这样可以支持更多的特性更灵活的业务处理。
在这种时候 nginx 只是一个单纯的 反代服务器， 他只有一个作用，反代，完全不会参与代码执行，，这时候就不是进程内的方法调用了， 而是网络传输，nginx 去代用户发起了一个 http 请求到后端服务器上，这种情况 nginx 不会接收到异常调用栈的，这时候他实际上是不会涉及 500 错误的。 只会发生 502 ，504 ，这种 nginx 访问后端超时的错误。

如果这种反代的情况下还触发了 500 ，那只能说明 nginx 除了反代还做了其他功能，比如 lua 脚本或者其他插件进行限流等操作时候发生了 bug 。

总结一下问题。

运营发现访问不了，喊运维，
运维粗查监控没有宕机，甩锅前端，
前端一看 500 错误，就觉得这是后端的错，甩锅后端。
后端一看返回的是 nginx 的页面，而且访问的还是前端的路径(聊天里说的)，和我有 p 关系？

最后前端出来发帖："现在后端都这么好干吗》"

----------------------------

期待后续楼主出来解答一下到底谁的问题， 看看谁是真的在甩锅。

我唯一能想到的 前端项目路径报 500 还会是后端引起的情况就是 —— 你们是 SPA 应用做了首屏服务端渲染，然后服务端渲染时调用后端 api 报错。
有人知道其他可能性的话麻烦也给我讲讲。

我初步猜测，最有可能的情况是 500 的访问链接是代码拼接生成的，但拼接了特殊符号或者什么其他内容，导致反代解析出问题；
除此外要么是 WAF 相关设置有毛病，要么反代服务器配置有问题或者写了 Lua 脚本但出 bug 了。

@wonderfulcxm
如果后端报 500 错，会由后端的服务器程序以自己的格式返回错误信息，对于 java 的后端而言是 tomcat 或者其他程序，而不是 openresty 的标准 500 页面。
不信的话你自己用 node 起一个服务让他访问就 500 ，然后你用 openresty/nginx 反代套一层，自己访问看一下会不会出现 openresty 的 500 页面。

网上看了看教学视频， 然后去池子里扑腾了 5 次学会了蛙泳。
第一次第二次连飘起来都做不到，别说游了， 后面第三次基本学会了大概，可以憋着一口气游几米，第 4 第 5 次都是在找手脚配合抬头换气的节奏。

@huangmingyou 是不是那个什么保洁大妈去把散热扇拔了充电的那个？ 检查的人去的时候大妈看着有人就没进去拔。

@dingwen07 现在说的是前端哈希，正常情况后端会自己做加密以及摘要，脱裤了攻击者拿到的也是无用的数据，你拿到前端的哈希那攻击者还能登录，但拿到数据库的密码字段是纯粹无用字段，除了 md5 和 sha1 其他方式攻击者都无法用彩虹表反解，连在本站登录都不能做到，如何危害其他网站安全？

而且这偏题了，提名是说 https ， 我的意思是 https 没那么容易被监听，所以前端不要自己做哈希， 你要是 http 那你爱怎么折腾怎么折腾去，我虽然依然觉得前端哈希不如前端 RSA ，但好歹比裸奔强。

@Buges 有影响，你前端哈希了如何做弱密码禁止相关的策略？ 写个 5M 的 js 来个穷举？

@Buges 我承认你说的这个问题，但我个人还是认为 https 不太容易被攻击，前端 hash 的缺点高于优点。
同时我说了我觉得前端要做可以做非对称加密

我今天用招行 app 的时候发现招行可以直接 nfc 读取身份证信息，在苹果手机上现在原来可以 nfc 了

当然 @GuuJiang 也理解错了一点他们的说法， 他们的说法是说 前端后端各做自己的哈希。
数据库存储的密码在他们的设计里是 后端:hash( 前端:hash(用户输入+前端固定 salt) + 每个用户个人 salt)。

这在后端眼里只是对于本站而言，等于脱了裤子放屁，用户密码由 123 变成了 a2cf ，但攻击者拿到的就是 a2cf ，拿到就能登录，对后端完全没区别。

@dingwen07
@g531956119
@Buges

我赞同 @GuuJiang 的观点，前端不要闲得没事自己做哈希，你们是准备把弱密码库之类的也写个 js 库自己前端做校验吗？然后弱密码策略也前端自己维护一份？比如什么密码包含生日包含连续数字包含账户名这种？

当然如果做加密我不反对，尤其是用非对称的，前端 js 里固定公钥就行，后端可以在注册和登录的时候照常反解回来，然后各种安全服务可以照常调用，弱密码相似密码也都不用前端处理，就是后端高并发的性能会差一些。

而且 https 被监听的问题我觉得不会如后端被脱裤那样容易引起大范围反应，https 要被攻击者解密我只知道让用户手动信任中间人的证书这一种情况。
除此之外我只听说过只有之前沃通还是那个 CA 的 bug 会给人发 gitpage.io 的根域名证书，然后这个 CA 就被浏览器火速拉黑了。

@dingwen07
@g531956119
@Buges
你们说的东西和人家 @GuuJiang 说的是两个概念。
人家说的是 即便监听者拿到的是前端哈希后的值，那在当前网站依然被黑了，对于本站和明文传递没区别。A 网站的用户在 A 网站的密码还是暴露了，攻击者可以随意登录。

而你们在说攻击者拦截了流量会危害到使用相同账号密码的其他网站，A 网站用户泄露的密码会导致 BC 网站同样被可以攻击者登录。

我赞同你们说的存在的问题，但这个问题和人家提的点关联性不大，即便按你们说的加 hash 了，那人家提的 A 网站被攻破了的问题你们并没有扛住了，那为什么说的好像人家说错了一样。

而且强 native -> 而是强 native