最后
关于面试刷题也是有方法可言的，建议最好是按照专题来进行，然后由基础到高级，由浅入深来，效果会更好。当然，这些内容我也全部整理在一份pdf文档内，分成了以下几大专题：
- Java基础部分
- 算法与编程
- 数据库部分
- 流行的框架与新技术（Spring+SpringCloud+SpringCloudAlibaba）
这份面试文档当然不止这些内容，实际上像JVM、设计模式、ZK、MQ、数据结构等其他部分的面试内容均有涉及，因为文章篇幅，就不全部在这里阐述了。
作为一名程序员，阶段性的学习是必不可少的，而且需要保持一定的持续性，这次在这个阶段内，我对一些重点的知识点进行了系统的复习，一方面巩固了自己的基础，另一方面也提升了自己的知识广度和深度。
这样会将userId暴漏在url中，不安全。解决方案：url做成通用的，数据请求需要用户自己主动触发（百度的）（不建议使用）
思路二：访问都需要登陆操作，session中放入userId， 记录中放入userId，每次访问的时候根据url中记录id 得到数据，根据数据中的userId 和session中的userId 是否匹配判断是否是用户本人访问？但是这样就会导致需要查询数据库之后才可以得知结果，解决方案：redis替数据库做用户验证。
思路三：用户访问订单的请求地址时带一个token，采用token，jwt加时间戳，放到每次请求的header中，拿到token进行校验，判断是否为该用户自己的账户，如果是则进行请求，如果不是则提示，转请求错误的页面。（这个需要前端在用户点击发请求时将token带上）
思路四：后台系统层面做一个授权与鉴权。所以虽然URL一样，但只有登陆授权过的用户才能让他看指定的数据。
思路五：在路由地方增加一个中间件，把需要验证的路由全部走这个中间件。每次用户登录的时候生成一个比较长的hash码（保证每个用户不重复） session 保存这个 hash。每次请求的时候验证这个 hash 就好了。每次登录都不同，不纯在泄漏问题。（和思路三类似，而且还多一个路由中间件）
思路六：拿浏览器的Cookie和缓存中用户id的数据对比
总结
虽然我个人也经常自嘲，十年之后要去成为外卖专员，但实际上依靠自身的努力，是能够减少三十五岁之后的焦虑的，毕竟好的架构师并不多。
架构师，是我们大部分技术人的职业目标，一名好的架构师来源于机遇(公司)、个人努力(吃得苦、肯钻研)、天分(真的热爱)的三者协作的结果，实践+机遇+努力才能助你成为优秀的架构师。
如果你也想成为一名好的架构师，那或许这份Java成长笔记你需要阅读阅读，希望能够对你的职业发展有所帮助。
ps://bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)**
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
