从大学开始用 php 在做外包，以前一位师兄吐槽 Java 很难用、臃肿，所以一直不太敢深入接触 Java。。。。。过了很久，当我再次深入学习之后，被迫完成大量项目之后，

发现 Java 太好用了，特别适合大型、多人协作、长时间开发、长时间更新支持的软件了，如果是用 PHP 或者 Python 的话，我一直都害怕某个对象预期的属性是 undefined （特别是我手上的有些项目都持续交付开发三四年了）

我也感觉出来了，万象城的天才确实要和蔼一点；太古里的天才有点藐视“屌丝”，如果你是达官贵人，估计会上来跪舔

说不准真有人拆零件拿去卖的哦，现在买个电子设备真的要多长个心眼，我去过几次 App Store 修电脑，遇到了两次有人拿组装的 iPhone 来进行维修，场面一度非常尴尬。。。

不用拆其他精密零件，拆电池就好了，电池还是比较好拆的。。。

反正我知道很多品牌都有线上专供版和线下版之分（我以前买的电风扇写明是电商专供，质量确实感觉有点次），而且线上专供和线下版很多质量要求、品控是不一样的。

苹果就不知道了，毕竟没在富士康车间混过，不清楚各个产地之间有没什么区别，不作评论。

盼星星盼月亮啊，大学时期的移动号一直保留着，走到哪带到哪，什么时候可以携号转网转地区啊

使用 shutduwn.sh 比较安全

顺便分享一下，一般我们是先从负载均衡移除了节点之后几分钟再进行关闭，这个时候基本上没用户在请求这个节点了，相对来说比较安全。

navicat 有结构对比功能

你的头像很有个性，是蛙蛙还是？

友情提醒，水电线路要用照片或者视频记录下来。

BTW: 重要的位置或者房间（例如电视墙、书房）可以布置两条网线，以后总会用到的，相信我。

我折腾过这些东东，所以还是比较了解的。

如果是使用家庭带宽作为服务器，遇到的问题就是：
1 ）小区断电、断网，对于普通住宅小区这是很正常的事情
2 ）网络不是特别稳定，提供的 HTTP 服务会间歇性地被 reset，应该是电信的某种探测机制会进行干扰。

针对没法使用 80 端口的问题，解决方案：
可以把需要 web 访问的域名放到又拍云上面，配合 CDN 动态资源加速，用户 -> 又拍云（ 80 ） -> 家庭服务器（ 443 ），这样就可以实现低成本的 80 访问方案。重点：不过需要备案才能接入它这个功能，另外由于电信的干扰，用户会经常被 reset，体验肯定不好。

针对家庭宽带公网 IP 会改变的问题，解决方案：
目前我们这边是重启路由器会改变公网 IP、隔两天会重新分配公网 IP，所以我之前的做法是，在路由器上进行定时重启设置，每天凌晨自动重启，这样基本上一天之内公网 IP 不会改变，似乎比较稳定。

针对 DDNS 的问题，解决方案：
我用的是 dnspod，通过一段 python 脚本实现自动刷新 dns 记录，使用自己的程序最大的好处就是，可以调高检测频率，发现 IP 改变之后马上刷新 dns。

-------------------------------------------------------------------

不过现在我还是买的阿里云服务器（之前从参加的活动，非常便宜），省心，不用担心断电断网的情况；

@hzw 同感，最近我已经基本没在京东买东西了。

京享值什么玩意儿嘛，随意改变规则（虽然我买了 plus 免邮券不受影响 ），说不定哪天又改规则。

搞活动涨价两倍妥妥的，不用三方比价软件的话，总有人会掉坑里面。

R7800 从 959 涨到 1999，幸好我在苏宁 899 买的

额。自从办理了交通信用卡之后，一年查我 N 次记录，显示是“贷后管理”

修正：“一个多页了” 修正为 “一个多月了”

我之前在美区用 PayPal 遇到诡异的问题，就是同一笔订单被支付了三次，但我的信用卡只入账了一次，另外两次一直是入账中，打 apple 中国一直打不通，信用卡也不入账（都一个多页了），不知道这两笔钱要怎么办。

@panpanpan

一定要根据自身 APP 的特点哈，我做了一些规则来对设备进行分数评价（这些规则只要不泄露，写爬虫的人肯定不知道），例如：

1 ）调用注册之前一定会调用拉取过首页广告的接口
2 ）一个 IP + deviceId 只会在 60s 内至多调用一次验证码发送接口
3 ）以及更多的特定应用规则

基本原理就是说系统会根据设备的访问历史记录，对请求进行动态评分，并且在 Nginx 这一层 "恶搞" 分数特别低的一些爬虫，甚至是 ban 掉。

如果有哪些 IP + deviceId 违反了上面的规则，我就会对这台设备进行扣分，当分数低于某个阈值的时候，会通过 OpenResty 直接返回相应的错误，而不是转发到后端程序。

专有网络，如果你选择经典网络，以后升级到专有网络挺麻烦的（如果程序多的话）

经典网络内网环境恶劣，经常会有被扫描、被流量攻击的情况，我们只从换到了专有网络后统一了入口、防火墙策略等，现在很省心

@honeycomb

没什么大惊小怪的，其他方案也有的是

如果只有存储权限，也可以不用 IMEI 的，只要能确定用户身份即可，之前我们做法是在应用存储区域写一个随机字符串文件，如果存在则在请求的时候发送这个；如果不存在，则生成后再携带发送。

----------------------------------------------------------------------------------------------

不过既然人家都能破解了，，肯定直接替换接口里面的参数，这个时候就可以根据请求请求对 IP 和 deviceID 进行评分，低于某个评分的情况就直接 ban 掉。

如果是还没上线，那好办，接口里面一定要通过某种方式传递一些设备信息（例如 IMEI 等）来识别身份；并且要保留验证码机制，根据该设备的请求情况决定是否在关键步骤中开启验证码模式。

如果是已经上线，但只能取到 IP，那可以根据 IP 维度对用户的请求进行监控，例如连续多次访问敏感接口（发送验证码之类的）则可以考虑对这个 IP 进行降权处理，访问某些接口的时候被 ban 掉。

------------------------------------------------------------------------------

上面可能需要利用到的技术就是复杂验证码、Nginx 动态编程。Nginx 动态编程可以考虑 OpenResty