大部分人都偏离主题了，当然也可能是我理解错楼主的意思了。

我觉得楼主是指对于自己见到别人困难但却因各扫门前雪的心态而没有帮助别人而感到自责，
并不是因为怀疑对方会讹人的而故意不帮，然后纠结对方究竟是真不舒服还是讹人，万一他是真不舒服而自责。

是对自己的莫管他人瓦上霜的自私心态感到自责， 而不是对有 1/2 的概率是真困难的人保有怀疑而不帮的困惑。


对于 对自己没帮人而觉得自己自私而愧疚 来说， 只能说大家都是凡人 庸人，我们都很难做到无私，而且心怀愧疚说明我们还是希望这个世界这个社会是向善向美的，这次愧疚后悔，那么没准下次遇上则会多犹豫一下就帮人一把了呢。

这种心态很常见， 我曾经见到小偷在我面前偷前一个推着自行车上台阶的姑娘的手机，，偷完之后俩人站在远处观望姑娘在台阶上找手机及路人是否告诉她，然而我并没有敢行动，怀着自责愧疚继续去地铁站挤早高峰了，然而之后还有下次估计还是依旧只能自责愧疚并没有胆量做出行动。

我第一次是煮辣椒汤+背好几个树枝加柴火，就和出殡的那个习俗一样，走一段地上点个火，强行一路走过去的，爬墙过水举不了火把的地方就吃辣椒汤。

@Pactzhao 确实是馊主意，但是主要是这样是属于激化矛盾引人嫉恨。单纯捕猎角度讲这难度对猫真不是问题，只要不是那种只会卖萌踩奶连老鼠都搞不定的小猫，这个鸽笼挂在窗外就是盘菜。

上初中那会，我们那住六楼的养鸽子户把谁谁家的猫套着勒死了都不算特别新奇的新闻。

@linjinbao66 不想给外部访问访问端口的权限就在开放端口的时候指定监听的 ip，比如

-p 127.0.0.1:37461:80
-p 192.168.0.100:8080:80

买个大的气球装一半的水， 然后窝成帽子形状戴在头上。

离职前把未完成的任务做完不是应该的吗....
难道还真能做一半扔下就跑啊？

提这种要求就属于恶心了？ 那真对不起, 我背叛了工人阶级...

其实这一切的问题根源是什么呢，是当年要尽快搞活经济，黑猫白猫的。

养老出了之后没倒闭的国企还是会给所有工人交的，不论是什么螺丝厂还是什么糖厂供销社之类的，反正这钱不是厂长自己兜里的。
私企老板就不一样了，多克扣一些工人的钱自己就多一分。
再来私有制改革走的比法律快多了，今天常见的许多法律法典都是 90 年代中后期才版本的。 而且中国的执法情况是普遍不执法，犯法也只要没有人闹那就没人管。都是运动式的执法， 什么严打、扫黑除恶、反腐、只有运动时候是真正严格执法的。

所以实际流程是。

国家 希望将社会福利的部分成本转嫁给资本企业 ->
然后资本企业又将这部分成本转嫁给了被剥削的工人阶级，而且非核心富庶地区这种事还没有人管 ->
被迫自己承担除国家支出外的全部社会福利成本的工人阶级认为是国家将社会福利的成本转嫁给了自己。


所以问题的本质不是正常缴纳五险一金时的成本与收益是否合算。
而是 被转移了成本的工人需要像个体经营户 /企业家一样，自己同时负担福利成本中的个人部分和公司部分，因此不论最终福利多与少基本肯定时不合算的。


所以解决方案：
调整缴纳费用❌
落实监管处罚企业违法不为员工缴纳社保的情况❎(该这么做然而不可能)
维持现状逐步增强对企业纳税和为员工缴纳社保的监管✅ (就像国内版权意识和法律执行情况的循序渐进慢慢来)


至于这个过程中倒霉的那群人呢？ 谁叫你没赶上呢，对于宏观层面上来说就是些微不足道的 1%~3%。

有你这种需求的都是发行俩版本，代码一模一样就是包含的 license 不一样。

包含开源 license 的版本限制禁止商业使用。

语言文字决定了除了中日没一个弹幕网站能活，除非弹幕只让发 emoji 。

另外就是二刺螈浓度不够的地方，对弹幕文化无感。

我支持关键不顶用啊。
所有的网站最主要的就是内容。你需要搞定的仅仅是内容提供者，鸡有了 蛋自然慢慢就多了。
现存的几个网站没个是靠观看的普通用户支撑起来的。


而内容咋来？
版权视频： 电影电视剧 你烧钱烧的过腾讯视频、爱奇艺、搜狐、优酷吗？ 动画相关的烧的过 b 站、爱奇艺、a 站、优酷吗？
个人创作者：你靠什么把 b 站、抖音、快手、a 站上的中小创作者吸引到你的环境上？

思考好这些你网站就成了， 腾讯爱奇艺的 ssssssvip 再被骂，有些人该买还是买了。

@winfield 实测还是差不少的，不过国营的不差钱就是大气，无损音乐不开会员一样听。

因为懂得真不多，网上各类文档教材也都是做个小 demo，能从请求到数据库再渲染出页面来就算完了。
从没见过几个真正的完整实现了一个基本网站的小项目。
所以只敢看个热闹，不知道该怎么用这玩意做一个和平时随手搭的 spring 项目功能一致完整项目。

如今我还是这个意思， 互联网应用会收到远超过去的传统行业的项目的并发轰炸。
但数据本身的复杂性和量级则大多不如过去传统企业项目。

因为过去数据结构复杂但机器性能有限，所以出现了数据库三范式，以及使用索引，外键，存储过程各种可以优化查询与执行的方法。

如今对于互联网企业 并发巨大，但机器其实廉价且性能比较富裕，毕竟并发可以通过横向扩展多机分担，而不像当年程序本身在这机器上满载执行就那么慢你能有什么办法。

所以在互联网企业时代，什么狗屁数据库三范式，我数据冗余存多份，每个关联数据里不止存操作人 id，连他的用户名和头像一起存下来，查的时候单查一个表，不比你多表查询快么。再不够就加缓存，当前显示准不准又有什么重要的。

这是我很久之前在另一个外键相关问题里的想法，（说外键影响性能） https://v2ex.com/t/626162

zpf124 166 天前

对于外键影响性能这点我一直持保留态度，如今的传统互联网项目的结构性数据都不一定有 20 年前的银行这类传统大型企业数据量大。
而当年那些企业哪个不用外键？ 如果性能影响真的大，当年计算性能比现在低那么多肯定早就有公司和产品将不用外键推广出来了。


外键对于如今而言最大的缺点其实是灵活性，曾经许多方法和算法为了高性能都用存储过程写到了数据库里，而这些年在互联网企业的示范下我们将这些都挪到了后端代码里，并且从前几年就开始流行将代码再向前挪——GraphQL，因为性能其实没那么吃紧了， 大不了找方法做横向扩展加机器嘛。

而这个时候对于业务层而言，后面那些层就仅仅是提供数据的，只要准确快速即可，业务层自己是就是全功能的，自己来给用户做约束，而不希望后面那些层再额外限制约束业务层影响业务层的功能。
在这种思考方式下，如果他是后端代码实现逻辑的，那么它就不希望数据库来存在存储过程，外键，等在后端代码控制范围外的约束来干扰它。
如果是 GraphQL 的那则是希望连后端代码都别做太多约束限制影响它的查询。

以 java 来说。

1 、(重点原因) 数据库设计的范式、老师讲课的内容，教我们的就是尽量降低时间复杂度和空间复杂度。
int 能存的数据不要用 bigint，vchar(10)够用就不要用 vchar(200)。

因此在设计数据库（我不知道现在还有几家公司是有专门的数据库设计人员参与开发的，反正我见到的都是程序开发自己设计表）的字段时我们的就是使用 int byte char 之类的长度较小的字段存储这类枚举值的，只会在注释里写一下每个枚举对应的解释。 也因此会习惯性的将接口也设计成直接传这个枚举值。
如果传字符串也不是不可以，后端自己 switch case 一下传过来的字符串，将他们转成对应的枚举值就行了，就是要是添加了新值的话，那后端程序每个传这个数据的接口都得更新一遍 switch case，麻烦。

2 、jdk7 才支持 switch （ string ）， 但历史惯性让我们更习惯于使用 int 。
并且在懒得自己做压测、不知道 jdk 对 string 优化到什么程度的情况下，一般的 javaer 会自然的认为 switch case 一个 int 、char 和 enum 的性能是高于字符串的。

@so898 就是我说的那次升级 iOS12 丢数据然后图表生成也卡了。