“不同意就不能用，并且没人治”的大前提下，你要用了就别再谈隐私了。

在 win10 这边就别想解决方案了，老老实实路由器吧。win10 上标准的 VPN，是给正规 VPN 用的，不能用来爬梯子—— PPTP、L2TP 特征太明显； OpenVPN 特征明显并且还未知原因用不了； IKEv2 未知原因用不了。至于未知原因是什么，可能跟 win10 在中国没被封锁有关。

请设置 JVM 参数（-Xmx)，JVM 申请的是进程独占内存，如果不设置，默认情况下，按照最小 25%物理内存，最大 50%物理内存去申请，4 个 java 进程就 GG，不管你加多少内存条。

你分析了这么多，就是没有分析赢利点。

QQ 及其衍生品，尝试过多种盈利模式，但能坚挺的就道具 /会员收费、给腾讯游戏分流这两种盈利模式，可以统称为“会员以及免费”盈利模式。这是要直接从消费者手里赚钱的，必然臃肿。

微信至今没从微信会员中赚过一分钱，它的盈利来源是公众号服务费、支付手续费等等，这是从商家手里分钱的。

虽然两个都需要庞大的会员数量作为前提，会员上还有交叉，但是它们是完全不同的两个产品。这种情况，让两个并存，并且不正面交锋，才是最好的选择。

@chuanqirenwu #6 你是真不懂还是故意装不懂公司内网的意思。

如果让用手机的话，Microsoft TODO & OneNote。否则，你就只能“纸质笔记本+回家手动同步”了。

@wjfz #14 已 block，不用谢，打这几个字倒不用多长时间。

@wjfz #7 一看你这就没做过数据设计。谁赞谁，这是一个多对多的关系，除非特别重要才会设计成实体，否则它就是依附于其它实体的关系，关系表上就两列：谁赞、赞谁，根本不会去存点赞时间。如果只有传统的 CRUD 架构，那这种情况下，是绝对统计不出来某段时间某个人收到的点赞数的，你连某段时间的总点赞数都统计不出来。

写完上段，我又略微拓展了以下，发现即使点赞关系是三个列——谁赞、赞谁、点赞时间，你的那个需求也是出不来的，因为多对多关系表行太多，是不会存储历史数据的。你不知道 2018 年 1 月 1 日中午点的赞，是那个中午点的赞，还是 2017 年点的赞但在那个中午取消并重新点赞。

你放心，只要过年放假还是 3 天，运力就永远跟不上。

@jhdxr #40 本来旧帖子在那一堆洗地的人里面没 block 你，因为你当时并不是太了解事情。然而 9 天过去了依然在洗地，那就补上 block。

老板自己把自己开了吧。

设置好自动重启时间，另外别一见弹框就去点。

不能查看数据，能随时停止订阅。

@hoyixi #43 无知不是福。

@mikeven #37 别听他瞎吹，超过 30%的，不是富人税，就是“我不想让你用”税，房租没这么高。

@xomix #2 简单个 P，要真这么简单，公司成立的时候，为什么不过户？个人东西被公司无偿使用的情况，就被你这么简单的分析了，你是真牛逼。

刚找到的信息：
财产租赁所得
支付财产租赁所得的，每次收入不超过四千元的，减除费用八百元；四千元以上的，减除百分之二十的费用，其余额为应纳税所得额，乘以百分之二十的比例税率计算税款

个税是需要自己申报的，房东不主动申报，就是漏税。以前不好查，所有漏就漏了，现在你要是报上了房东个人信息，他来年就不得不主动申报了。

房租税率是 20%，抵扣最高 1500，自己算一下得失吧。工资不够 8000 （最高减 45 ）的，或者房租超过 1500 （最少加 140 ），基本就别费那功夫了。

本来还以为是什么大事，原来又是一个给门加锁却不好好保管钥匙的故事。