@judgingwoo #9 根据 https://injoy.work/archives/5068ac38.html 的了解，基本上就三个字——智商税。而且，它的实际价格也没超过￥ 100 / 月。

还以为是多高的价格，拉到底一看，机场服务，感觉这“如此高的价格”应该不超过￥ 100。机场服务本来就是灰产，拿 tos 说事也是秀。

既然你发在了 Android 区，那么首先，正式渠道应当是 Google Play 内购。其次，Google Play 内购有门槛，国内支付渠道的门槛更高——压根就不支持个人收款。这点上也能看出为啥个人开发者喜欢 IOS，至少支付渠道上简单。

之前不分配，就是这种特殊号码不好分配，结果 APNIC 和 Cloudflare 硬要顶上去，不抽他就说不过去。

批评及问题
科技网站称 Cloudflare 使用 1.1.1.1 作为域名解析服务的 IP 地址将导致不符合互联网标准（例如 RFC 1918 ）的已有设置问题。虽然 1.1.1.1 并非保留 IP 地址，但它却被许多路由器（大多数由思科系统销售）、托管登录至专用网的企业、退出页或其他用途所使用，导致 1.1.1.1 将无法被手动配置为这些系统的 DNS 服务器。 [6][7]此外，1.1.1.1 被诸多网络及 ISP 所封禁，因为这一简简单单的 IP 地址意味着其先前被用于测试目的与非法使用。这些先前用途使得大量垃圾数据涌入 Cloudflare 的服务器。

1.1.1.1 与 1.0.0.1 的清除
1.0.0.0/8 IP 块于 2010 年被分配给 APNIC，[8]在此之前它是一块未分配的空间。[9]然而未分配的空间与私人使用的保留 IP 空间（即保留 IP 地址）不同。[10]例如 AT&T 声称他们正修复其 CPE 硬件中的 CPE 问题[11]。

@xuanbg #172 2XX 全部是正常返回，3XX 虽然不是返回内容但也是正常返回，网络问题一般是 4XX。服务器本身问题，包括业务逻辑问题，HTTP 状态码是 500 或者 5XX。你那种要么 200 要么无返回的接口，并不是 RESTful 风格的接口。

经过十几天努力，终于将路由器配置成了透明代理——虽然只能针对固定配置出来的 IP 地址做代理，将 trakt.tv creativecommons.org 的四个 IP 配置上之之后，电脑端不管是浏览器还是 UWP app 都能正常访问这两个网站了。（理论上，因为 Cloudflare 的 IP 地址是连续的，可以把 Cloudflare 的 IP 地址掩码配置上去，从而彻底远离百毒云减速，不过没试。）

该解决方法仍然用到了代理服务器，不过至少首次配置完成后，后续使用的时候简单了。

虽然努力了十几天，但绝大部分时间都是再搞路由器（完全重刷了两次），代理程序的安装只用了一天，网关转发规则花了一天时间去找方案，但配置起来就只是在防火墙自定义规则中加了这么几句：

ipset -X extend_ips
ipset create extend_ips hash:net
for ip in $(cat /root/gateway_extend_ips.txt);
do ipset add extend_ips $ip;
done
iptables -t nat -A PREROUTING -p tcp -m set --match-set extend_ips dst -j REDIRECT --to-port 56789

我没有顺便把***list 自动**给配置上，那个虽然找到了方法，但是预测没个 5 天的奋斗，是配置不起来的。

可惜的是，手机还用不了。这逼走的是 ipv6 的通道，上面配置的透明代理不起作用。经过 ip6tables 多次尝试，我的路由器的 ipv6 模式下，网关都不是路由器，手机直接以 ipv6 地址接入公网了。

@yamedie #75
@pkoukk #81
@Amayadream #86
三位一看就没设计过错误代码，根据登录接口的不同返回情况做不同的后续交互处理，这是登录功能自己的事，并不是全局通用规则，所以这些不同错误情况的代码，应当放到 data 中，而不是 code 中。

@icris #79 http 404 的友好返回是：HTTP CODE 404，并且 body 做一个像那么回事的界面。见 https://github.com/bbbbbb/bbbbb，你需要开发者工具才能看到返回的 HTTP 状态码。HTTP 404 只是个状态码，并不表示浏览器遇到 404 就不会继续显示页面；而 HTTP 200 + 404 界面，对浏览器之外的其他前端——比如搜索引擎——可能产生干扰。

@h82258652 RESTful 风格要求的是“使用 HTTP 状态码指示接口的执行结果”，并不是“只使用 HTTP 状态码指示结果”，它并不反对你同时使用 HTTP 状态码和数据中的“code”。结果包一层并不违反 RESTful 风格。当然，恒定 HTTP 200，仅使用数据中的“code”表示错误码，这是违反风格的。

一个优良的服务或接口应该在尽量简单的情况下兼容不同的前端，有些前端——比如临时测试并且操作人还懒得打开 F12 的浏览器——可能没有接受 HTTP 状态码的能力，这时候他就需要从返回的 JSON 数据中去获取 HTTP 状态码。一个优良的接口，首先肯定要根据实际情况返回 HTTP 状态码，其次返回内容应该是这样的：
HTTP CODE：NNN
{
"http_code": NNN,
"message": "bula bula",
"main_data":{...}
}
或者是这样的：
HTTP CODE：NNN
{
"http_code": NNN,
"businesslogic_code": NNNNNNN,
"message": "bula bula",
"main_data":{...}
}
第二种情况，如果没有提供 businesslogic_code 的翻译器，businesslogic_code 不管是对前端程序还是对前端的用户来说，都是神秘代码，屁用没有（这个代码，windows 生态中的 800nnnnnxxx 错误代码，是个典型的代表）。在错误反馈中，字符串类型的 message 才是必要的，数字 code 只是可选的。

1. 必须请假的，但可以争取先电话后当面，不排除部分公司（尤其是刚腾出名额的时候）会电话一遍过。
注意，不安排电话面试的公司，直接排除。真正想招人——不管是名额腾出来了还是紧急招人——的时候，不会那么强势，如果强势的要求必须去现场面试，大概率是面向 KPI 面试。晚上 7 点或周末面试的，基本也可以排除的，这个不用多说。

2. 在职无所谓的，甚至更有优势。
只要不是急招，等一个月就是小 kiss。对于正规公司来说，Offer 审批通过并收到确认，这个名额就算补上去了，人事（招聘负责人）的工作就算完成了，他很少会在意你是立刻入职还是一个月后入职。
急招大多是坑，还是错过的好。

3. 同 2。
Offer 反悔的概率不高的，你看看你自己骑驴找马要花的精力就知道了，一般拿到第一份 Offer 就该安心准备离职了，不会再寻找更好的西瓜。

4. 目前只要公开简历，就不可能不被发现，骑驴找马的过程中最好是定向主动投递简历。



然而实际上还是裸辞并休整后集中找工作更好。

本来想说你现在不离职将来问题会更大，但是你在杭州，我啥也不说了，自求多福。

你这个好麻烦。Keepass+Onedrive （或者其他同步工具）就够了，

@Allianzcortex #20 在我的印象中，Github 的主要目的是代码开源，次要目的是代码托管，再次要的是协同开发，趋势这功能就像大多数首页上的图表一样，是一个没啥用又不能没有的鸡肋功能，不关心是正常的。
@gz911122 #29 没事别乱开炮，开炮也开准点，spring 正在主推响应式。以及，想跑之前请先学会走——比如英语读写能力和翻译工具使用能力。

看了你的补充回复，你爸比你会投资，请听你爸的。另外，投资有风险，风险要自己但，绝对不能把风险转嫁给亲人。

你使劲哭，我先屏蔽了。求职就求职，表什么白。表白就表白，敲什么锣。

一个功能一个分支的多分支开发，请每天首先从主分支向个人分支 rebase，就像以前 SVN 的每日 update 一样。这样你就可以尽早的发现冲突，虽然不能减少总的冲突解决时间，但是能让你的工作计划更合理。

记得每日 rebase 的时候截图一下冲突情况，对于多次发生的同一种冲突要及时上报。

订阅收费模式，永远不要关注优惠活动，没意义，最典型的就是域名优惠——首年$1 以后$10。