https://www.google.com/search?q=site:gov.cn+filetype:xls+学校

我翻了一下，教育部的网站只公布大学名单。中学阶段的没找到，也许需要扫整个 gov.cn 的域下面的 xls 信息自己收集，一般能找到就至少是一个市的名录，所以人工清洗的工作量应该还属于可以接受的范围。
此外我发现教育部正在推进一个叫做学籍管理系统的事情，要求各省必须做好从小学开始的学籍管理。所以如果你有办法买到内部人员帮你导出来的名录，应该可以一次搞定一个省份名录。

优势：
服务器 cpu 负载低，全都到磁盘 io 负载上面了。
部署简单，有磁盘加一个 web 容器做静态站配置就能拉起来服务。


劣势：
磁盘占用空间大，不容易迁移分发
不容易发现文件损坏导致的数据丢失
难以调整网页信息，类似更新标题或者网页结构的时候，会消耗非常长的时间在生成页面上。

内部系统的话别管那么多规范了，先跑起来服务就可以。

检测恶意参数是优先级最高的，不要相信任何客户端传过来的数据，所有参数都必须校验。是否考虑异步要看提供的服务是不是延时很高的，如果一个正常请求可能要几秒才能把处理好的数据返回，就需要考虑用异步框架在前面把请求都接住。后端开多台服务器提高负载能力，如果只是普通的业务，什么开发快用什么就好。

测试的时候，有时间做边缘数据测试最好，要不至少也得在开发的时候考虑用户有没有可能传负数之类的数据，如果没有那么多时间，可以在编写代码的时候就采取防御式编程作为 RESTful 接口的策略。

如果请求参数已经可能超过 GET 的限制，要放到 POST 里面做，那就不太符合 RESTful 的接口语义，等于应该分在 GET 和 POST 的资源操作都被合并到 POST 里面了，会导致你可能需要在 URL 上面做区分。
比如 /source 是资源的 URL ，按 RESTful 的语义， GET 是获取 /source 的数据， POST 是新增 /source 的数据，你都合并到 POST 接口，可能就要在 URL 上面做区分，/getsource /newsource 这样才能实现资源的区分度。

如果存在这种可能，或许不使用 RESTful 比较好，就在 URL 上面做语义区分。毕竟先提供服务才是主要的任务。能保证某些接口的幂等性就能少掉很多网络延迟导致的异常。

@call43848
这样的机制太伤用户体验。非常影响用户口碑。现在连用户滥用批量注册账号都不会管，还费精力去做回收账号这种吃力不讨好影响自己口碑的事情？

腾讯以前倒是做过回收账号这事情，直接在用户申请协议上面要求，注册之后必须在限期内登录激活，并且超过多长时间不登录就会回收账号，那会儿估计是赶上账号系统资源不足没升级，服务器资源不够做了限流，实际上根本没有执行。现在有钱了更不会做这档傻事。

网易也做过回收账号的事情，声称 180 天不登录会冻结，然后回收。实际也不执行。

Gmail 也做在用户协议上面写过，超长时间不登录会被锁定注销，但是账号资源不会放出来。

个人感觉，账号系统的维护成本是比较低的，真到系统资源紧张要回收账号的程度，要么很快可以调度资源扩容，要么这个服务也许很快就要整个关闭了。
Google N 个服务说关就关。
雅虎邮箱整个关掉。
百度空间也是说关就关。
商业的东西谁能说个准，缺钱了就关掉了。

实在想要好的邮箱还可以自己花钱买域名做自己的域名邮箱。
QQ 可以花钱买靓号。
Google 财大气粗， Gmail 是没有靓号买了。

我觉得还是看官方文档+stackoverflow 的效果直接。
最好是有个动手的项目来实践，做 Web 应用似乎不太好想复杂业务来练习， MongoDB 用来做清洗数据可以有效提高对它的了解程度。
一个是录入数据的压力比较容易在代码层面调整。
另一个是做数据报表会刺激自己寻找各种奇怪结构的数据如何抽取。
配合几个数据清洗和做报表的实践，应该就能对 MongoDB 有哪些性能的坑有初步了解了。

先做功能，再丑也不要紧，只要功能可以解决需求，有用户才有优化的动力。
第一版尽可能用原生的框架 UI 的组件，不要怕丑，因为框架自带的组件再简陋也是风格一致的设计，在没有审美的情况下，自己选各种组件去拼接出来界面的会更丑。
也不要想着用业界比较酷炫的 UI 库，你会发现虽然官方 UI 丑，但是文档齐全出错好找解决方案，各种 UI 库哪怕是大厂出的，在对 APP 系统接口不够了解的情况下使用等于在同时学两套接口，出错查起来会有无从下手的感觉。

交互是个大坑，尽可能按官方的交互手册来，而且要保持一致性，不要出现一个操作模式在不同地方有不一致的响应，不要拍脑门想快捷操作，因为程序员的思路和普通用户真的不一样，比如用户习惯了左右滑动代表拖动列表数据的话，就不要在某些地方出现左右滑动操作前进后退的事情了，反之亦然。
iOS 的用户被系统教育了长按的操作习惯， Android 用户习惯这个操作的很少很少，如果是 Android 藏在长按触发的功能可能不会被用户发现。
类似的还有双击触发、多点触摸拖动这类看起来便捷的技巧，不写清楚引导的话，有可能用户完全发现不了，虽然写了用户也不一定会记得住，所以是不是要用这种高级技巧看有没有时间写代码吧。

"标签列表"->"详细介绍"->"另一个标签列表"->"另一个详细介绍" ->"又一个标签列表"。这里有个坑，如果没有复用组件的机制，反复点下去，会出现一个很长的调用栈，用户可能会返回到吐血。如果复用了又可能不符合用户的预期，比如超长的列表被重载了丢失操作历史。这个最好先想好用户可能更习惯那种交互。

APP 的缓存和存储是个巨坑， iOS 有系统约束的清除规则， Android 有神奇的 SD 卡读写权限约束。
iOS 还好只要读一个发行版的规范就好，读完手册不要犯该持久化的文件存在缓存被系统删掉的错误。
Android 各家修改的 rom 权限略有微调，还没有文档，只能靠猜，如果是 Android 的话最好找个有经验的帮忙，至少碰到问题可以问个方向。

iOS 虽然官方框架限制很多，但是真心对独立开发者友好，用户升级积极性高，几乎都是新版本系统，只要按着官方文档用官方的原生框架就能做出来一个还过得去的 APP 出来。 Android 有些机型真的很坑，不要想着兼容大多数主流版本，个人开发的话，能做到 4.0 正常， 5.0 、 6.0 不因为神奇的权限问题闪退就不错了。
决定自己开发很有趣，我踩过的坑就这些印象比较深刻的，希望能对楼主有帮助。

我用 admin LTE 做过管理后台模板。 admin LTE 要想用好光靠后端渲染是不够的，好多 admin LTE 集成的插件是要写 JavaScript 的代码的，获取后端的数据之后通过 JS 来做数据渲染。
如果是想快速在 admin LTE 上面做开发，建议不要用 Django 集成的模板，拆成 restful 的形式， Django 、 flask 、 tornado 什么框架都好，只提供 API 接口。交互效果全部交给 admin LTE 的各种插件完成。这样开发起来会轻松一些。

其实 admin LTE 这种形式的交互效果，如果要做的业务比较复杂的话，写起来 JavaScript 的代码量还是挺多的，因为要写很多网络请求的接口去拿数据。尤其你的任务系统可能会用到报表，还可能要集成不同的报表插件，所以不要对 admin LTE 抱太大的改造希望。这是一个庞大的管理后台模板，很多效果都是靠不同的插件完成的，实际开发的时候可能要去好几个不同的插件官网查看文档，做好这个心理准备。

如果有时间和精力学习 JavaScript ，我觉得可以考虑用用 vuejs 方面的模板，我是个主后端的开发，做个人项目的时候最头疼的就是前端交互的逻辑，因为做出来的又丑又繁琐，接触 vuejs 之后，仅仅就是用 vue 替代 jQuery 就省去了我很多写前端渲染的精力，所以在这里推荐一下 vuejs ，考虑一下用它替换 jQuery 试试看？

话说楼主一直提 native 在抓取各种数据聚合上面多么多么方便，恐怕不知道马化腾已经在人大提交过打击聚合类 app 的提案，并且很多手握版权的公司都在合力起诉那些聚合类 app 的持有者，以侵权为起诉理由，颇有抓住一个就往死里揍的阵势吧。
任何一个做原创内容的公司，都非常讨厌侵权这种事情，转载过去就算了，直接构造请求一点成本不出就占用服务器资源，这种做法等于在抢钱吧。

类似愿意开放资源访问的，通常都在 get 接口上面开放，哪怕是 POST 或者 PUT 的业务，只要按照其文档提交的请求，都能拿到相关的资源。根本不存在楼主说的有意愿开放访问但是受限于浏览器限制没有办法开放的情况。浏览器不能构造任何请求不是行业的业务痛点，反而是浏览器这个领域保护用户的重要优点。
楼主发的这个话题，更像是一种泄愤，为什么浏览器不能让我想盗取什么就盗取资源。我在 native 上面盗用起来何其方便，在浏览器上面怎么就这么难，这浏览器是不是要死要死了。

如果是 3 年以下的 php ，我个人感觉分几个级别：
1. 计算机基础不扎实的，比如操作系统原理、网络通信、数据库原理、算法与数据结构没有办法自学的
2. 项目经验少， CURD 方面的代码写的比较多，没有机会重构业务或者编写高并发业务代码的
3. 异常处理经验少，对于突发的系统故障，没有机会调试，或者没有掌握调试技巧，不能有效分析 log 和系统参数找性能瓶颈的。
4. 没有机会参与一个完整业务的框架搭建，不能理解框架在工程规范和业务增长兼容上面如何取舍的。

这份大纲似乎没有在根源上面找准做 web 开发应该提升的技能，用工具可以有效提升工作效率，但是仅仅靠工具似乎更像是换了一把锋利的剑，没有找准对手的死穴，不能一击毙命，不算一部好的武林秘籍。
看这份大纲有种有趣的感觉。就像买了一本武林秘籍，推销的老人各种吹嘘学完这部就能功力大增行走江湖不再被人欺压。翻开书一看，竟然是：
如何购买一把锋利的宝剑
选择一件优质防尘披风的几个要点
组队战站位的几种方式
执剑的几个起手式样本
选择一匹良驹的关注点
如何在酒馆与店小二讲价
论几种夜行衣的穿着体验

问题是学完这些，该被人吊打的时候还是得乖乖跪下认打啊。

其实这份教学大纲也有不少有用的东西，比如 linux 的安装配置之类的， git 的协作技巧，翻墙的方法。但是这并不够，对特别初级的太杂乱没有主线，对有一定基础的又不够深入，花式技巧太多没有抓住重点。
认真的说，作为一个入门的 web 开发人员，不管任何语言，要说有一份晋级初级开发的技巧想让我付费。我希望除了说服我要打好基础，认真学完什么算法与数据结构、网络通信原理、操作系统原理、数据库原理之类的说教之外。有这么一些内容。
1. 如何搭建测试环境以及组件选型的几个测试要点。如果能以此为实例讲面对两三个可选组件的时候，怎么去测试并选择一个合适的组件。要是能用上 docker 做实例讲解更好。
2. 高并发状态下，几种 sql 语句的性能对比。如果以此为实例，讲讲怎么用测试工具构造请求施加压力给服务器，数据库如何做 explain ，以及对于相关情景下面优化的 sql 语句之所以高效率的原理。
3. 实战演示高负载状态下的服务器性能瓶颈分析。以此为实例，讲讲 linux 服务器的运行参数如何查看，对于 cpu 负载、内存消耗负载、磁盘读写负载、网络 io 负载如何查看以及对应资源不够用的时候会出现的现象。如果可以深入相关的业务分析是什么业务导致的性能瓶颈，以及在遇到瓶颈之后在考虑加硬件还是改代码的决策要点。
4. xx 设计模式在搭建框架的应用。以此讲讲业务增长的不同阶段业务代码应该如何抽象，应该遵循什么工程规范避免低级的开发错误。能用实际参数讲讲在请求量达到什么阶段会崩掉，怎么不会过度设计之类的更好。
5. 分布式系统搭建过程中要避免的几种代码。讲讲如果遇到了需要横向扩展的系统，在数据库设计的时候如何拆分，在分布式系统中应该牺牲哪些性能用于加强系统健壮性，缓存颗粒度以及在应该在哪些级别的业务考虑缓存。


这些都是有能力编写初级代码，但是进一步提升可能会遇到的门槛，并且这些没办法完全靠文档和资料去学习，非常需要有经验的人引导才能迈过去。并且这种经验不是正常的业务代码开发有机会遇到的，不幸的是如果没有在校招的时候进入合适的公司，可能没机会去接触类似的业务场景。而如果没有解决类似业务场景的经验，有可能永远没办法通过具有这种业务场景的公司的面试。

如果是进阶初级工程师的教程是这些，我相信愿意为此付费的人会挺多。毕竟讲讲入门的培训机构学费都得 1w 起，进阶初级的课程 1w 起一点也不过分吧。

你想写 native 抓各种 api ，那是因为 native 你可以任意构造请求数据，所以没有同源安全这个限制。但是浏览器不可能放开这个限制，因为浏览器托管了 cookie 这类的敏感数据是可以做用户标识的，所以发出去的请求格式有限制，不能任意构造请求。
即便是 native 的开发，也还有存储域的限制，一个 app 如果在框架指定的私有存储域写入文件，那么别的 app 也不可以访问到这个私有存储域的文件。而且最重要的一点， native 不可以调用用户浏览器数据或者其它 app 的资源，只能靠 native 自己构造请求数据。

而浏览器对于 web 请求，是不验证发起域的，只要发出去的请求，默认就带上该域的 cookie 作为用户标识。所以 web 目前的请求方式决定了，限制跨域是保证浏览器用户数据安全的底线，不管任何浏览器都必须支持同源安全限制。只有符合 cors 白名单的网站才可以发跨域请求。

如果浏览器在目前的业务下可以在任意界面构造任何请求发出去，这个浏览器不可能有人会使用。如果所有浏览器都没有同源安全限制，那互联网不超过一周就崩盘了，你随便访问一个不知名的网站，它就在后台给一票网银系统构造转账请求，在你不知情的情况下，钱就消失了。对网站来说，自己站点提供的服务，图片、 api 这类的，别的网站可以不告而取，任意调用。

你想这么做，我猜测的原因可能是，你希望在自己的网页调用别人的资源，并且是别的网站没有在 cors 开放权限的资源。这种情况下你依然想调用这个资源，那就只剩你想盗用别人的资源这个情况了。
碰到这种不能调用的资源，要么你找对方网站在 cors 上面加上你的网站域名，允许你直接调用。要么你自己开服务器做反代，转成同域请求。


以后浏览器如果可以任意构造请求，那就要改变浏览器的请求模式，对于非同源的域发起的请求，比如 A.com 网页中构造了一个向 B.com 的请求，那这个请求拿不到任何 B.com 存储在浏览器的数据，相当于一个独立的用户发起的请求。比如 A.com 网页向 B.com 发出的请求永远不能携带 cookie 和敏感的 header 数据。

这种情况下，才可能出现任意网页调用任意域的 api 数据。否则只会出现更多欺诈用户的现象。对行业生态和用户都是伤害。

对于小型项目被 DDOS 。
第一，找机房，机房能不能帮忙清洗流量。如果不能，可不可以通过增加带宽的方式把流量吃下来，吃得下来就有机会找办法清洗。
第二，此机房已被打跨或者机房不愿意清洗流量，考虑临时上 CDN ，先把服务降级，先保证服务器的非交互可以正常展现，比如首页之类的。
第三，实在不行就请求机房关闭外网，先走内网连接登录服务器改改安全配置，只要不是带宽被 D 光的攻击，比如 CPU 或者内容消耗型的，找找性能瓶颈或者降级业务，先保证服务器能提供基本业务。

如果又用不起可以清洗流量的机房，又没钱买 CDN ，那就等死。

此外网站安全靠代码， windows 上面的安全狗之类的都是 cpu 大户，所有请求全拦截进行分析，装上去，没等别人 DDOS ，用户流量大一点，就先把服务器 CPU 爆掉了，最好不要浪费资源在这种软件上面。

临时迁移域名解析有个坑，用户的 DNS 解析记录更新是很慢的，如果就服务器没有做好反代新服务器的配置。
直接切换并且旧服务器关闭，大概率面临某些地区用户丢失一周无法访问。
如果迁移没有关闭旧服务器，又不做反代或者数据同步方案，大概率出现某些地区用户依然访问旧服务器数据分裂不一致。

推广普通话的国家的战略意义重大，就和秦统一文字和度量一样，是加强国家执政效率、经济流通的重要手段。
基于这个大背景下方言边缘化是正常的。毕竟方便交流的普通话有义务教育、电视等富媒体内容加成。
目前学术上面对方言的研究不仅仅是训诂学、语言发音这类的，每一门方言的词语里面都记载着对应群体的迁移史，我知道的就有根据方言中的词语与其它方言借用的比例，推测持有此门方言的群体大致迁入的时间以及在迁移过程中可能与其他方言群体交流的程度。这对研究不同时期的人口流动是有帮助的。
方言和传说是流动的史书，边缘化是正常的，但是如果一门方言真的消逝了，那这个方言对应的群体过往的历史可能就少了一个追溯的渠道。

比如非洲布须曼人（ Bushmen ），他们独有的吸气式发音绝对是对人类语言发展研究的重要材料之一，如果现代化将掌握这些语言的群体全部转化成持英语发音的群体，几代之后，人类可能就会忘了这个语言曾经存在过，这个群体过往的历史也会随着现代化进程被遗忘，最多只能根据 DNA 的序列进行人种方面的分析，这个群体曾经的文化、人类学、民族学信息则很难追溯了。

建国初期为了分析民族迁移的过程，有一个方式就是分析方言的发音、词语之间的借用比率，根据民族传说去配合史料记载，找寻一个民族的原住地以及迁移路线。

国内目前对方言的这种做法实在是很难理解，持有方言是落后文化，要让方言随现代化进程消逝这种想法的人挺多的。如果这样，那解放初为各个无文字的民族制定标准音标和文字的语言学者付出的努力还有什么意义？

方言会边缘化，但是如果可以调整对方言的态度，不要以落后文化必须要淘汰的态度去处理方言与普通话之间的争议，给后世的人保留一点追溯群体过往历史的渠道，总不算什么坏事。


我就举个方言融入普通话的词语例子：
“漏风” 用这个词来形容一个原先是干燥物体，在包装密封性不够的情况下，受潮之后出现的一种松软、甚至粘稠的状态。但不是发霉或者变质。
在正常交流的时候常用的方式：
这包饼干漏风了。意思是这包饼干拆包装之后，受潮松软了，咬在嘴里没有酥脆的感觉。
这包糖 /盐漏风了。意思是这包糖 /盐虽然包起来了，但是因为吸收空气中的水份，变得粘稠甚至融化的情况。

这个词语在闽南语系的聚集地还有东南亚很多国家都通用。

如果仅仅是按照点击率排序，不引入时间段的权重，这个不太容易解决。

我觉得基于目前只计算点击率的方案，不做大改动的情况下， 0 点重置榜单之后，可以考虑默认榜单取过去 12 个小时内新建的文章作为初始种子数据，按点击量排。这样可以在一定程度上面减少老文章的马太效应。

如果榜单不一定要填满，也可以考虑在 0 点重置榜单之后留空榜单，设置一个进入热门榜单的点击量门槛，比如重置后只有 1000 个点击以上才能进入热门榜单。这样可以解决初始化榜单的问题，只有在正常浏览中点击量达到真正热门标准的才会上榜。

举报有用，这种属于倒卖公司资源。很多互联网公司都存在这种情况，在外面开个公司，利用内部消息灵通及人际关系的便利，做一些内幕消息或者流量变现。举报之后就看什么时候高层斗争，这都是斗争的时候可以用到的武器，至于谁是举报人根本不重要。

@tammy 我个人感觉是，如果原来的业务用什么语言，需要抓取数据的时候，就看是不是特别嵌入原来的业务，需要特别频繁调用原有数据做检测的，那就用原来项目的语言，可以很方便的复用原有项目的代码做检测和插入数据。

爬虫这类的业务可大可小，用什么脚本语言写，性能都不会有特别明显的差距，主要还是看工程规范，用什么语言写全看团队成员的技术栈。

我个人比较喜欢 curl 库+v8 库+正则的方案。 curl 库解决 header cookies https 的各种问题， v8 解决某些 js 加密的问题。正则解决抽取数据的问题。 CPU 和内存消耗都比较低。

然而实际上如果只考虑一个语言的话， nodejs 解决所有问题。

任何语言只要能发网络请求都可以写爬虫。
python 爬虫通常是用增强库，用来帮助解析网页数据。
php 写爬虫通常是用 curl 库+re 正则解析，可以借助 curl 的库做很多参数设置， header cookie 之类的。抽取数据是靠正则来做解析。需要自己写任务管理。
如果爬虫是强嵌入原有业务的，比如需要取很多业务数据做检测，那就用 php 继续写爬虫，封装一个 curl 的处理接口，然后写一个多进程任务管理，要用到命令行的库，通常要借助 mysql 、 redis 之类的做进程间数据同步。

如果仅仅只是为了一次性抓取数据， python 上手也很快，一周绰绰有余。

属于原有机房集群部署的经验迁移。
过去一个出口后面会存在很多台服务器，这些服务器之中很多都不开放外网访问权限。所以外网管理集群的时候，会单独设置一台 vpn 服务器，作为跳板，让外网管理员通过连接 vpn 进入集群内网，通过 vpn 帐号权限设置，可以减少很多管理风险。

现在只有几台阿里云服务器的时候看不出来这么做的好处，但是如果服务器数量多了，可以设置阿里云的 ssh 访问端口只允许某个 ip 的服务器访问，这样可以根据 vpn 帐号约束管理操作。配合 ssh key 的校验。可以避免员工流动之后带来的管理风险。