@aaa0009 哦哦，这个意思，了解了

没看明白，获取 refer 怎么防钓鱼站

@daolin 已离职多年😂

等 NEO 啊

@daolin 邀请注册都是 8 月 28 之后了，作为前微博员工这个 B 我还能装一下

@daolin 你这 B 装大了哈，新浪微博 2009 年 8 月 13 日内测的。

@mswlander 不客气，账号安全还是要注意的。
1. 账号分级管理，特别是涉及钱财的支付、银行账号，绑定的手机号邮箱以及密码单独设置，别和其他账户重复。
2. 各类账号绑定的邮箱手机号要保证尽可能安全，邮箱建议使用带有两步验证功能的邮箱（ Gmail 、 hotmail ），绑定手机号所用手机别越狱别 root 别乱装盗版软件。
3. 一旦手机被盗，建议立即拨打电话冻结手机号码，废弃的手机号在停用前尽可能和之前绑定账号解绑。
4. 密码尽可能复杂，且涉及钱财和个人隐私的账户密码不定期更换。
5. 账号支持动态密保、两步验证的全部开启，把账号安全度提到最高。
6. 实在记不住密码和绑定关系的，建议借助 1Password 这种三方工具辅助记忆。
7. 对不常用不熟悉站点，别用三方账号授权（特别是微博。微博这块用户资料获取、发博等权限管理一直很混乱，冷不丁中招没处说理去。），可以尝试用替身邮或者临时邮箱+密码记录工具来辅助注册登录。

做到上面 7 条的，基本账户安全保障是有了

@jarlyyn 是的，账号安全设计这块有个基本原则叫做「钥匙请保管好」，做安全只能尽可能保证不用正确钥匙我不让你进，但你说别人偷了你钥匙打开了门没法怪防盗门不好。

虽然说可以利用以往登录行为等特征做识别，但成本很高，平台方也没有义务去做这块（除非涉及交易比如支付宝这种央行是强制做多因素验证的）。

@mswlander 是的，所以说到这块，微博的安全工具解绑流程确实存在缺陷的，理论上应该是可以做交叉验证解绑的，猜测是为了提高安全等级一刀切了（防止邮箱被盗后通过邮箱解绑手机号）。

登录注册这块设计本来就很见产品和技术功底，所以我在另一个帖子下面说过，我作为老产品汪，对新入行产品考最多的题就是「如果你的产品需要登录注册，请画出全部流程并简要设计原型。」至今没有哪个两年以下工作经验的产品能一口气完成的。

微博这块基础功能，包括它的反垃圾策略，我也已经无力吐槽了。这平台就这样吧，来去总广告费赚的爽，股东们看着股价节节高升，其他都不是事儿 ╮(╯▽╰)╭

@mswlander 要是已经身份证实名了，若注册邮箱你还能用，试试我提供的办法自助找回密码并解绑原手机号吧，能解决。

另外，记得修改密码，绑定新浪微盾（微博官方动态密保），限制登录地，并将应用中心里的可疑及不常用授权全部取消。这很重要。

至于微博客服，确实渣，但人也有理不给你办。用户量大了以后说实话人工客服的成本十分高，且客服都是外包之类的，也解决不了这种账号安全问题。
你看 QQ 账号，现在一样没人工客服了，实在是成本过大。

@mathcoder23 Linux 下绘图……你真不考虑用 Python+Matplotlib 么……这样的话自增什么的完全无压力

@jininij 不一定是被官方卖，也有可能是利用了你以前的三方应用授权，被盗号找回密码后第一件事是修改密码，绑定新浪微盾（微博官方动态密保），限制登录地，并将应用中心里的可疑及不常用授权全部取消。如果绑定了动态密保，授权取消干净，且本身手机号码安全还被盗，那基本可以证明是官方作祟

@mswlander 在知道原有手机号情况下可以解绑
1 试试用邮箱找回密码登录（如果能登录此步跳过）
2 在登录状态上传身份证做实名验证。
3 账户安全中心，修改绑定手机号
4 输入原手机号点下一步
5 选无法接收短信（类似）
6 用身份证号验证并绑定新手机号

抛开微博客服垃圾不谈，这块流程设置是有点儿问题，理论上应该可以利用绑定的安全邮箱作为验证手段强制解绑手机号，估计是为了安全等级提高没有做。

微博现在的流程也不能说错，当站方无法确定你是否知晓原手机号且无其他硬性验证信息时，完全可以拒绝你的申诉。

USB 连接 Mac ，用 QuickTime 直接投射上然后录屏怎么破？

@mathcoder23
起始单元格填好自己要的起始数据，工具栏选 [填充] ——> [系列] ，设置好步长值，终止值等项就可以自动自增生成了

我知道的是酷狗的盈利确实来自于秀场业务（酷狗繁星直播），音乐本身不太赚钱这是行业普遍问题。

公司的话，严格意义上说只有一个产品经理，叫谢振宇😂

合并后酷狗的话语权在集团没还是很重的，毕竟用户量摆在那里。

不过这些都跟普通员工关系不大，搬砖的就安心搬砖完了。

想了解啥？行业动态？公司氛围？薪酬？你倒是写明白点啊

简单了解的话一本《图解 HTTP 》够了，配合 Paw 或者浏览器自带工具看请求内容格式基本够了。《 HTTP 权威指南》太厚了，而且里面涉及到很多服务端知识，一般开发用不到，除非你想做运维。

@notgod QQ ……