你是在哪里收到通知的？我也去看看

一直喜欢在天涯看贴，爱好八卦，😺

@Vegetable

好的，谢谢了。目前我们 APP 嵌入的网页也要求能够在浏览器里面正常打开，正常分享。所以有很多考虑。

@diferent 所言极是。

@Vegetable

我们也做了一些讨论，觉得你的方案很不错，当 APP 访问网页时就把 token 放到链接中，当网页里面打开其他链接时也把 Token 带上。

但有一个问题，如果用户不小心把这个东西分享出去了，那就很危险了，相当于泄露了这些信息。

你们是如何处理这个问题的呢？望解答，谢谢

@oott123

嗯，对的。我们会陆陆续续把我们要指定的各种规范和架构能开放出来的都开放出来，让更多人参与讨论和思考。

@kkkkkrua

经过商议和讨论，我们还是希望遵循一个大原则：就是除非 Token 失效返回 HTTP Status Code 外，其他情况都返回 200，但业务在处理参数校验、未处理异常这些公共错误时，还是要通过 resultCode 传递给调用端，让他们知道是怎么回事，方便给用户进行提示。

@ochatokori 嗯，非常感谢你这个反馈，我马上测试一下，我之前还真不知道。

所以说把问题拿出来分享有很多人好处，避免闭门造车。

最终我们会把所有规范和流程能开放的都开放出来。

@baiyi

非常感谢你的建议。

其实很多时候都不是那么理想化，推进一个东西不仅要科学，更多的时候还要考虑人为配合的问题，也许你这个方案非常好，但别人就是故意不配合，那也很尴尬的，所以我们要征得内部大多数人的赞同才行。

当然放到 V2EX 讨论是希望能够得到更多的意见和建议。

另外，我刚刚和同事沟通了，网页通过 bridge 的方式通过 APP 或者小程序都比较稳定，没必要通过统一拦截返回状态码的方式来发现是否 Token 是否过期。

@Vegetable 这倒是一个不错的方案

APP 跳转到网页，网页里面有 ajax 这个似乎都能够处理。那网页里面打开其他链接地址是否也可以呢？例如通过 js 拦截点击请求，把 Token 也添加到目标地址里面。

非常感谢这个方案，非常有建设性的意见。

@linxl

感谢反馈，这个问题，我会跟进的。

你用流量，别人是可以拿到基站和定位的历史数据（从运营商直接拿或者分析其他用户历史定位的对应关系）
你用 WiFi，同理。

后台是可以看到可疑打卡记录的，不要尝试，没用的，一堆程序员早都想到了。

说个真实的，昨天在公司楼下被电动门夹了（当时有点事，停留在门中间掏出手机低头开消息），右边的电动门突然自动关闭很重地打在我的眼镜上（半框，没全框结实），当时心想完了镜片肯定得碎或者被划伤（其实最担心的还是我的眼睛是否受伤，要是镜片碎了估计得出事），回家擦洗干净后发现完好如初，不过我的眼眶被玻璃边界打了上下两道血印，现在都还在。

镜片和镜框还是买个好的，对自己好点，毕竟很久才换一次。我一直在博士用依视路镜片，之前用过一次其他杂牌子，用了几天就换回来了。

@leon0903 其实很正常，每个公司、公司内的每个团队都有自己的风格，所以项目结构是不可能统一的，只要能说服大家或者强制推动大家使用就可以了。

@gz911122 哦哦，这个倒挺有意思的，主要是我希望认为参与越少越好，免得出错

@gz911122
1. 第一次听到弹性环境这个词，请问有更多资料吗？我想了解和学习一下
2. 我们单个微服务内的集成测试是没有把 MySQL、Redis 等 mock，因为我们会对数据库里面的一些记录做断言。
3. 我们把测试依赖的基础代码写到 sever-test 的 main 里面的，而不是 test，是为了在测试阶段其他模块可以服用代码。
4. 嗯，这只是我们目前的模式

再次感谢，不吝赐教

我说一下为什么我们要把这些东西放到 github，主要有以下原因：
* 不希望我们再固步自封，我们希望和大家沟通技术，改正我们错的地方，也希望吸收新的想法和实践。
* 希望通过 github 持续输出一些我们的最佳实践和技术规范，帮助到有需要的人，这个过程中我们也可以完善自己的标准体系。