要是在企业，你这样做，出问题了，你就准备捡包袱走人吧。
在学校，网管为了安全封闭了 22 ，只允许 443,80 ，就是说只允许 web 开放，你别作死，擅自改 22 端口，出问题可大可小的。

1 万-1.5 万，去外地，你折腾呢！

go 更适合写中间件吧，写业务代码感觉好难受。

如果后端开发就 3,5 个人的话写微服务拆分得太细会很痛苦。对于小公司，从公司角度还是建议一个单体 jar 走天下。
但对于个人发展，当练手吧。

@xwayway 您现在的处境和我很像。小银行，招我过来想搞点内部小的应用，觉得服务商不划算，干脆啥都让我干。像极了。

服务器端算时间。每隔一分钟发一次心跳。后台累计。这个过程要注意限制提交频率，防止一下子就刷完了时间。

感觉楼主没弄清外包驻场客户现场和国企客户是什么关系。
1.楼主和外包公司签的劳动合同，外包公司和国企客户签署劳务派遣合同。然后楼主作为外包公司的一员，派遣到国企干活。
2.国企活干完了，派遣合同不再续签，楼主就离开派遣地简称外包撤场。楼主回到外包公司，等待外包公司安排新的驻场工作，这段时间应该是只拿基本工资。
以上，无论哪一方都没有违法。
如果外包公司也一并把楼主裁了，那就是违法了。可以去仲裁外包公司。

还不如专门维护一个 sql 或者 json 。库真的没必要了

结论：代码挺好！简单易懂
缺陷：用了魔法数字，除了作者，我们都看不懂 2 是啥意思（某些方面来看，这也许是优点？）

op 不必多虑，劳务派遣基本是半年和劳务公司签订一次合同的。要搞你，直接在外包的时，半年后不和劳务公司续签你就得退场了。所以，转成正式员工后，尽管放心

@qtxxm 31 岁了,这些农、城商银行的问题是规模太小了，人事调动的很频繁。换句话说，即使是技术部门的人员，你一不小心就把你搞去做营销了。

刚跳到某农商行，银行也并不是那么好

积累一套自己的业务框架，新需求来啦直接就是 Controller ，service ，dao 的写业务。在这基础上用常见的高级语言，效率都是差不多的。

设置防火墙，只允许固定 ip 访问。比如家里 ip 会变动，就允许一段 /24 的 ip 访问，公司的直接固定 ip 。基本可以了

为何厚颜无耻？
人家没遵循原项目哪个条款？

那种方式舒服做那种，还真刻苦专研技术啊

个人觉得 win 宿主机+一个 linux 虚拟机就行了。linux 虚拟机直接装界面那种。linux 的开发直接在 linux 。windows 的就用 windows 。像数据库，redis 这些中间件，放 docker ，win 和 linux 公用

作为一个后端，layui 确实是门槛低！