没有这样的处理办法。老老实实签补充协议交押金吧，一般来说几万块就可以了。

@7654 所以拿过毒瘤广告费的公司就成了人类的希望了？你真是神逻辑。

@7654 别逗了。你可能是不知道 Mozilla 给员工发的钱的来源之一是 Google 的赞助费吧？

并非要招的人少啊。现在招人这么难，当然是能招到越多越好。
最终招得少是因为能通过面试的比较少而已。

@taresky 笑死 我首发买到了亮黑 7，7 天后到手。买到了就是买到了，市场价多少关我 P 事？

你买的是 200M 带宽，常规流量超带宽了可以买负载均衡，异常流量怕进黑洞可以买高防。
另外那个叫阈值，不是阀值。

@binux 高明一些的注册流程是输完用户名后用户就会知道该用户名是否已存在的，否则被占用还要等提交后才知道的话用户会很恼火的。

假设你的登录流程没这么高明，就算恶意用户懒得去试，这里依然是有漏洞的。并不是把找回密码做得没有漏洞就高枕无忧了。

@binux 你实现的注册功能是不是也不会告诉楼主用户名是否存在？😂

@mansur 是。但是你若是不买的话关你什么事？

这跟基因有关
最好的办法就是别找女朋友，不然以后儿子也得秃

@solaro int 或 bigint 没法处理小数位数，两个数相除时是要处理结果保留几位小数以及 ceiling(四舍五入 / 去尾 / 进一)的规则的，所以应该用(数学意义上的)decimal。
那哥们用 string 的原因是 php 这个所谓的最好的语言居然没有内置对 decimal 的支持，而是需要通过 bc extension 处理 string 来实现对 decimal 的操作。

@msg7086 我还是不明白你这个“所以”是怎么得出来的结论。用单机(无论 EC2 还是物理机)跑应用本身就是错的，机架断电 /机房断电 /断网 /空调挂掉 /有人手欠按了一下你电源你未必就不会遇上，至少要在双机房(在 AWS 上就是一个 region 的两个 az)做高可用才是正确的做法。

你偶尔登一次 EC2 发现 uptime 是个位数就可以说明 EC2 比想象中脆弱了？ 你怎么知道自己不是遇到了 1-SLA 那段时间？

@msg7086 以及你们的运维很成问题，主机监控和应用监控都没有？直到 ssh 到机器上了才发现不知什么时候机器被重启过了？
这个运维水平换了物理机照样会一个故障就致命的。

@msg7086 说明你的应用有问题。无论是物理机还是 EC2 都不可能保证 100 ％ uptime，你自己的应用不做 HA 只在单机上跑，出问题是迟早的事情。

@LioMore 不是，不要听本帖的草台班子们胡扯用什么 int。正确的方法是用 decimal。
PHP 用户可以看一下 http://de2.php.net/manual/en/ref.bc.php

@msg7086 为什么用云就得“要么你得雇个团队研发基于云 API 的自动部署系统，要么你就只能当单机用”？

我无论买二手服务器放机房还是买 EC2 得到的都是一个可以 ssh 上去的服务器，为啥后者就需要雇个团队研发基于云 API 的自动部署系统？买二手服务器就不是单机了？你要是说多买几台二手服务器就不是单机，那我多买几台 EC2 也并不是单机啊？