所以就没有人好奇为啥一定要做码农嘛？感觉干其他行业香点不好嘛？

战略性 mark~~

所以你为什么要去装 8 呢？ 7 不香吗？ docker 不香吗？ debian 不香吗 :dog

但凡这种帖子莫名好多人，好奇怪

有的，深夜都有人接。
心悦会员了解下
除此之外，希望到您孙子那一辈能联系到:dog

Cool.avi

只有我好奇楼主要拿那么精确的随机值用来干什么么？
小白没接触过大世面，求场景，求需求

万一过了，求老哥后续，再让我们乐一波，不是，不…不行了，哇哈哈哈哈哈哈，哎乐死了，希望老哥好运找到个好的

你小时候没玩过 剑侠系列么？这么多年一直在出游戏，武侠系列游戏里面非常知名的开发商，虽然我对后续网游系列不大感兴趣，但是经常看到广告，剑网三如上所说也是影响很大的一款大作。

虽然游戏不喜欢（主要没时间玩了），但是画风还是挺中意的，插画师 白姥姥 也画过很多剑网三的插画

现在的游戏感觉没有以前的有意思了，那会单机又没网还不懂攻略，愣是一个月通宵刷级，结果到了顶级一套带走 boss

我以为是 6sp

成月经贴了，好多人啊，看来还是别买了

对了，洗澡都还要你拖着他或者整个室友拖他看他开水并监督没 10 分钟不准出来的那种，哪怕是夏天 40°高温，脑补下

反正我宁愿自己没钱租个 10 平米我都不喜欢和人合租

体会下被子，枕头，床垫都发霉的那种还睡得很香的
2333333

我不是 我没有 别瞎说 最近改迷信了

@nicevar 如果不解决如何投产，只是底层框架没去修正后面也没去修，主程后面都走了，新来的不会，自己为了方便和用 ci3 才升级上去的

@gouchaoer2 ci2 的 cookie 都会放到一个字段上，而 session 要是没用其他 handle 驱动的话，都会放在 cookie 上，然后 cookie 进行 base64 后长度超过上限，cookie 上限大小是又限制的。
我们自己会使用第三方 handle 去处理 cookie 问题，session 也会加入驱动解决，可新手不会。这才有后面一系列项目持续出现这个问题，当时是出于教育目的去教他们如何解决如何处理所以没有去根本解决。
后面就是老是出现在这个问题上才直接去升级框架

楼上的大佬们脑洞真是可以，我只是阐述极小小小小小小小小小小小小一部分公司面对技术栈是如何选择的，在当前的情况下为何会这么选择。
选择完后要保证项目可控进度之外，如果不对其框架设计思想和原理进行解刨以及使用框架的目的和意义，那我要人干嘛，直接找个靠谱团队对接完事了。

使用框架的目的不就是为了保证项目的可控性和进度之外，学习优秀框架的设计思想么？包括框架对本项目的意义？
你们一群大佬坐在一起当然选择直接造轮子啊，直接选择发明一种语言啊框架啊。
我们这种菜鸟没本事才只能在前期先选择你们造好的轮子和框架去先活下来。不然我们什么都不懂的情况下造的轮子和框架让你们用？体会下一个项目除了 bug 和一堆眼瞎的代码？这不是纯粹找喷么？

感觉说多了都是找喷，v2er 都是大佬，你们牛，我就一彩笔，23333

故事 1
我们定当年 ci 框架的时候吧，基本上是公司里那几个领头也就是主程当时用着顺手能快速简单做起来投产，然后发觉框架太精简了，并且 ci2 有个知名的 cookie bug。然后一路升级封装拆分。

后来我实在受不了那个 bug，导致很多业务线干扰，刚好 ci3 稍微稳定了，我就直接升级上去。
之后就习得稳定大过天技能，那段时间带来的损失和几个月修 bug 让我之后远离了 ci，也懂得了没事别手欠去对投产项目搞什么新技术就是牛 x 一定要升级，谁在没把握的情况下升级谁傻逼。
这就是所谓的历史债务吧

不是说 ci 不好，当然也可能是写的太烂了，做个小项目 ci 还是小巧能干的，以至于小到稍微复杂些的业务就得自己造轮子。

但是对于入门学习来说还是很快的，当然了，现在各种技术的快速迭代升级和需求的更新 ci 已经显得有点那么力不从心。

故事 2
后面到我定前台技术栈的时候，
个人倾向于 yii2，不为什么，大!! 全!! 不谈什么臃肿复杂，反正不用怎么造轮子。
但是这方面人稍微比较难招，当时项目比较紧急
选 tp3 吧，看那语法不是说不好，只是感觉别扭感觉后期也是坑
当时 tp5 在 a1 阶段，还有的更新，抛弃。
那 laravel 吧？当时应该还在 4 阶段，看了下版本更新速度跨度过大，不熟，手底下班子也是急忙组的用不了
zf ？不!这是真臃肿了，本土氛围也不好
最终选 yii2 ？不，不合适，人员培训，招聘，成本，氛围都很勉强。

犹豫期间最终看 tp5 到 a2 了，还是 tp5 把，培训班生产，成本低，人多，质量不好可以外包。
就这么愉快的决定了!

为啥不选 java ？ go ？ py ？
1.成本高，老板不乐意
2.好的都在隔壁 A 厂和养猪厂了。
3.公司无法把控技术风险
所以还是选择我大 php 啦，又快又便宜，还满足当下
毕竟这个已经是跑着的业务不能轻易跨语言，对已有技术栈这样升级不是闲钱多么（主要是菜 :dog ）

最终定的 tp5 一路打怪升级进行对老业务的系统升级。
是的，没错，又一次挖了个巨坑，技术人员的整体水平不行以及新需求的不断推进。后面死翘翘了

故事 3
从 tp5 一直挖坑下去，多多少少大部分水平都慢慢上来了。都能写精炼框架了。为啥？中间放手他们自己去折腾了其他几个小框架，大大小小几个项目。花钱砸出来的（哭一会）。
最后，现在基本上就是 tp5 和 laravel5 混着用了，他们顺手用哪个，两个技术部门，交叉开发。
现在慢慢让他们往 c 拓展框架走
哦，后面还有一个独立技术小组，走的 java
前端那边提议开始用 vue，之前用 ag2
后端那边也开始折腾提议 go
代价有点大，但是挺开心嗯，就是经常心痛想砍人

故事 4
新项目上区块链
二话不说肯定 go 啦，不好招，java ？也难
C ？不可能，招不到。（别说钱的问题，问题是没）
后面定的
Go 做核心处理 api
Php 做前台 laravel5
Py3 爬虫
外包扎场前端 vue
不是说不好招么？怎么又搞上了，emmmm 核心逻辑 go 自己几个主程构架去写，php 负责前端业务和数据封装转换，爬虫内推了个
问题？有的，毕竟扎场还是属于外包，一个单页网站首页白屏 20 多秒体会下。拆页解决中。

以上就是个人遇见对框架选型以及历史遗产又或是外在影响最终导致的技术或框架选型之类的问题所见。
可能有点歪楼，手机码字，排版见谅

以上

一个之前案例，仅供参考

背景：

域名 a.com 10.0.0.2 （前端）, b.com 10.0.0.3 （接口）, ab 同内网

a 本机绑定 host：10.0.0.3 b.api.com

a 反向到当前 a 二级目录或者二级域名,nginx 拦截处理，也就是你们说的什么负载

请求是直接转发还是中间再加个什么代理或通信端口层自己看

例如我是直接 开了个转发端口 b.api.com:998

b 机器绑定 a 机器的指向域名（如果没有用 ip ）

这样也就是你所说的隐藏后台业务服务器

梳理下就是

a.com/login --拦截或处理-->> a.com/api/login --数据转发-->> b.api.com:998/login

效果大概如上

然后，对于如上方案，后面被 pass 了，从安全角度来说，确实做到了隐藏后端
只是我感觉吧，好麻烦，中间好几层消耗，太恶心了，没啥必要，纯粹增加时间和资源没什么意义

然后目前采用的做法是

前端-》中间处理层 -》后端

中间处理层与后端采用 rsa 通信，每 10 分钟更换通信 token

前端和中间层肯定有个基本的加密，例如你们常说的 jwt? 我是自己实现个内部算法

前端和中间处理层是一台服务器，后端是独立另外一台服务器

中间和后端的数据库不同

中间层放的是一些基础数据，后端放的是敏感数据

中间层往往是一个前端接口对应后端 n 个接口，最高的有 8 个接口对应一个前端接口

然后和楼上说的，你前端域名再走次 cdn

嗯，某种意义上来说，基本做到了完全隐藏你后端业务（大概，嗯是的）

当然，这套方案落下来，个人还是感觉好恶心，还在考虑其他优化方案，望大佬指点（递阔洛）