本期【云享专家·微话题】由云享专家 HuangJacky 与大家一起探讨“云端WAF技术”，希望大家能够畅所欲言。如果大家有其他相关的问题，也可以在本帖回复直接咨询云享专家 HuangJacky 。=======【云享专家·微话题】云端WAF技术 =======随着云计算的普及，客户更多业务迁移到云上，以往传统的配套安全服务也转变云上SaaS服务，Web应用防火墙（WAF）对业务无侵入，来划分安全和业务开发的职责，大大减轻业务安全工作量，因此成为云上客户标配安全服务之一。然而云上客户业务的多样性，流量大，这些都对云WAF提出了新的挑战。为了应对这些挑战，云WAF不断引入新的技术，比如利用机器学习打造更加智能更贴合业务的检测引擎，利用DPDK技术打造更高并发网关。我们始终相信技术创造未来，开启云WAF新时代。每个人对“云端WAF技术”都有不一样的理解，今天我们就“云端WAF技术”一起来讨论，希望看到大家精彩的评论：1. 云WAF和传统WAF的区别？2. 云WAF遇到的问题和误报？3. 机器学习和云WAF能做什么？4. 你期望云WAF应该具备哪些功能？微话题活动：参与本次微话题讨论，有机会获得优质评论奖活动时间：2018年8月20日-9月2日参与方式：直接在本帖回复你关于以上4个问题的理解或评论获奖方式：活动结束后，将由云享专家 HuangJacky 选取出3名优质评论奖，各送出《白帽子讲Web安全》书籍1本。

求助：基于华为云视频的视频点播功能web端开发的流程能否帮忙指点下？目前个人了解的基本如下：1，注册账号后按指导文档完成相应的操作，如视频转码设置，视频上传等。2，在视频转码后，在管理页面可以获取到当前视频的播放url等参数。在获取到相关参数后，是不是在一个简单的h5页面上直接播放即可（h5的video标签）？还是像安卓或者ios一样需要集成SDK？另：服务端的SDK是不是用来在app/web上直接对视频进行相关操作？刚研究，各位还请不吝赐教，谢谢。

ServerlessServerless中文译为“无服务器”，最早可以追溯到2012年Ken Fromm发表的《Why The Future Of Software And Apps Is Serverless》[1]，他描述了一种场景，从用户自己维护的物理机，到IaaS，再到PaaS，计算模式的转变并不会停止，在云计算基础设施成熟的情况下应用程序可以不需要考虑服务器的存在，无服务器计算让开发者可以在不考虑服务器的情况下构建并运行应用程序和服务。再到2016年，Mike Roberts在Martin Fowler的博客《Serverless Architectures》[2]中，将Serverless架构分为Backend as a Service(BaaS)和Functions as a Service(FaaS)。BaaS也就是后端即服务，即应用架构由大量三方云服务和API来组织，使应用中关于服务器的逻辑和状态都由服务提供方来管理。比如典型的单页应用（SPA）和移动APP这些富客户端应用，前后端的交互主要以Rest API调用为主，只需要调用服务提供方的API即可完成相应的功能，比如身份验证、数据访问等。FaaS可以被称为函数即服务，开发者可以直接将服务侧业务逻辑代码部署、运行在第三方提供的无状态计算容器中，开发者只需编写业务代码即可，无需关注服务器，且代码的执行是由事件触发的。一个Serverless的应用就是这样一个将BaaS和FaaS融合在一起的应用，用户关注于应用的业务逻辑代码，以函数为粒度将其运行在FaaS平台上，并和BaaS三方服务整合在一起，最后搭建一个完整的系统，整个过程完全无需关注服务器。Serverless的优势1、无需管理服务器开发者只需关注应用的业务逻辑，而无需关注服务器的存在，降低业务接入门槛，快速上线，提高开发和运维效率。2、灵活扩展、按需付费据Gartner和麦肯锡统计，全球的服务器CPU平均利用率只有6%到12%，大量应用的资源利用率是非常低下的，特别是对于负载波峰波谷明显的应用。而Serverless可以根据负载弹性伸缩，并按需付费，根据实际运行消耗的资源计费，且业务是以函数的粒度运行的，可以充分利用碎片资源，极大地减小运作成本。函数工作流FunctionGraph上面简单介绍了Serverless架构以及其优点之后，我们再介绍一下华为云的函数工作流（FunctionGraph，FGS）。函数工作流（FunctionGraph，FGS）是一项基于事件驱动的函数托管计算服务，托管函数具备以毫秒级弹性伸缩、免运维、高可靠的方式运行。通过函数工作流，开发者无需配置和管理服务器，只需关注业务逻辑，编写函数代码，以无服务器的方式构建应用，便能开发出一个弹性高可用的后端系统，并按实际运行消耗的资源计费。极大地提高了开发和运维效率，减小了运作成本。构建无服务器图片鉴黄web应用为了让大家对Serverless架构和函数工作流有更直观的了解，接下来我们将介绍如何通过函数工作流快速构建一个完整的无服务器的图片鉴黄Web应用，如下图，该应用接收用户上传的图片，并对图片进行分析，判断是否为**图片。试想，如果我们通过传统的模式开发此应用，需要如何开发？即使是基于现在的云平台，我们也仍需要购买云服务器，关注其规格、镜像、网络等各指标的选型和运维，然后在开发过程中可能还需要考虑与其他云服务的集成使用问题，使代码中耦合大量非业务代码，并且服务器等资源也并非是按需的，可能会造成大量多余的费用。现在我们可以通过函数工作流服务来快速构建这个系统，并且完全无需关注服务器，且按需运行，如图：创建函数，在函数中调用华为云内容检测服务提供的图片鉴黄接口，实现图片鉴黄功能，并为该函数配置一个APIG触发器，对外提供图片鉴黄的API，从而构建出一个完整的图片鉴黄无服务器后端。然后将Web页面的静态资源部署在对象存储服务（OBS）中，用户可以直接从OBS访问前端页面。用户上传图片时，页面调用前面构建的图片鉴黄API，他会自动触发函数执行，而开发者编写的函数只需实现接收到图片之后如何处理图片的逻辑（调用内容检测服务服务）即可，最后将结果返回给前端页面。至此，我们就构建了一个完整的无服务器图片鉴黄Web应用。现在，我们将介绍如何端到端地将此无服务器应用构建出来。后端API搭建：进入函数工作流服务函数创建页面，选择图片鉴黄模板。该模板已经提供了本应用中函数的代码，按照代码注释中的指示创建函数之后，就成功搭建了本应用的后端系统，为函数所创建的APIG触发器会提供一个调用该后端函数的HTTP(s) API，供外部系统（如前端页面）调用。创建成功后API的URL可以在函数详情页面的“触发器”栏看到：前端页面搭建：前端的展示形式有很多，这里我们提供了一份前端代码包供大家学习参考，可以将此代码包部署到OBS上，快速构建一个单页Web应用（SPA）。然后调用上一步后端提供的接口，连通后端系统，完成整个无服务图片鉴黄Web应用的构建。1、下载代码包并解压2、为了让前端页面访问您的函数，需要配置页面Rest请求的URL。修改代码包里/functiongraph/assets/config/apis.json文件中checkImage的值，更改为上一步“后端API搭建”中创建的APIG触发器URL，即您的后端API的访问地址。3、通过OBS托管前端页面。进入对象存储服务，创建一个OBS桶，将程序包文件逐个上传至该桶中。因为文件比较多，我们建议您下载 OBS Browser ，使用OBS Browser前，请先获取访问密钥。4、启动网站。进入桶的静态网站托管界面，单击静态网站托管，配置桶的默认首页为index.html。配置完成后，您就已经成功搭建了本案例的前端系统。您可以通过obs提供的访问地址访问您的前端页面，检测图片时，页面会发送请求到您的函数。总结通过上面端到端构建一个完整的无服务器图片鉴黄Web应用，我们可以发现Serverless的架构具有如下优点：无需关注任何服务器，只需关注核心业务逻辑，5分钟快速构建后端系统并上线，极大地提高了开发效率；函数运行随业务量弹性伸缩，按需付费，当创建的函数没有执行时，不计费。可以通过简单的配置连通函数工作流和其它云服务，甚至云服务和云服务，比如本例中只需创建一个APIG触发器便可完成API网关和函数工作流的连接，然后在函数中调用内容检测服务的鉴黄接口，那么函数就像一个粘合剂一样将两个云服务连接在一起。相关链接https://readwrite.com/2012/10/15/why-the-future-of-software-and-apps-is-serverless/https://martinfowler.com/articles/serverless.htmlhttps://console.huaweicloud.com/functiongraph/欢迎扫码查看更多精彩：

华为云数据库 SQL Server 新版本上线！ 目前已支持 2014 EE 版、2016 EE 版，2016 SE 版、2008 2014 2016 WEB 版。基于华为云最高性能硬件V5系列性能强悍基于华为云最高性能硬件V5系列，性能强低至 0.7 元 / 小时低至 0.7 元 / 小时同规格最便宜云数据库立即体验>>传送门部分新增功能预览：  支持按需转包周期支持错误日志下载支持备份文件按数据库粒度下载支持磁盘不限次数原地扩容支持链接服务器支持新实例还原，从低版本还原到高版本：web->标准版->企业版支持数据库重命名，实例按需批量购买，单实例转主备实例知识小贴士：1、SQL Server WEB 版，对于为从小规模至大规模 Web 资产提供可伸缩性、经济性和可管理性功能的 Web 宿主和 Web VAP 来说， SQL Server Web 版本是一项总拥有成本较低的选择。2、SQL Server EE版（企业版），提供全面的高端数据中心功能，性能优异且具有端到端的商业智能，支持最终用户访问深层数据。3、SQL Server SE版（标准版），提供基本数据管理和商业智能功能，使企业能够顺利运行其应用程序并支持常用开发工具。了解更多华为云数据库：戳这里最新优惠活动：戳这里

2017年末，Python软件基金会与JetBrains网站一起开展了Python开发人员调查，目的是确定最新趋势，并深入了解Python开发世界今日的样子。 根据结果显示，每5个Python开发人员就有4个将Python作为第一编程语言，所有使用Python作为其主要语言的开发人员中又有一半在使用JavaScript。使用Python作为辅助编程语言的开发人员更喜欢将其与JavaScript(46%)，C / C ++(42%)，Java(41%)和C#(24%)一起使用。 Web开发人员与数据科学家：谁在统治Python世界? “你用Python做什么?”这个问题的答案非常有趣。 事实证明，数据分析和web开发是最广泛的用途。 13703 1、使用Python进行数据分析和机器学习的占24%; 2、使用Python进行数据分析和web开发的同样占24%; 数据分析和机器学习的结合并不是什么新鲜事，但是和web开发相结合还是蛮令人惊讶的。可以肯定地说，从DevOps到机器学习和数据科学，Python无处不在。著名的编程网站Stack Overflow似乎也同意这一看法：Python是增长最快的编程语言。 13704 如果将数据分析和机器学习统称为数据科学，那么，使用Python进行web开发和数据科学的比例接近1:1。 结果：Web开发人员和数据科学家一起统治着Python世界。 Python一起使用的最流行的技术是什么? 结果显示，与Python一起使用的最流行技术是Jupyter Notebook，其次是Docker和Anaconda。 此外，接近70%的受访者使用AWS，其次是GAE，Heroku和DigitalOcean。 最后，PyCharm的两个版本是Python开发中最流行的工具，其次是Sublime，Vim，IDLE，Atom和VS Code。 本文转自：IT168网站

本帖最后由 码小玩 于 2018-3-2 17:29 编辑这个标题可能咋看之下似乎有那么一点怪(a little odd)，(不过你要知道，把标题起的这么怪真不是我的本意)，而我真正想看到的是，你们 web development 社区是如何看待web以及是如何看待 Web以及Chrome 开发者之间的协同配合。 接下来(讲述)的大部分内容，都是我直接从自己写的doc给摘录过来的，(至于doc写的是啥)?或许你们可以把它(简单的)理解为团队自己定下的(具有)高水准的目标(our high level goals as a team)吧。不过，我担心的是，接下来的内容可能讲的有点夸张(hyperbolic)，(不过说句实在话)，从长远来看，我内心还是希望所有与web开发相关的团队(developer relations team)都能够遵守。 (上面讲的内容)其实是可以变的(This isn’t set in stone)，不过我还是想围绕这个话题来和大家探讨一下。如果大家都能够给出一些反馈的话，我将不胜感激。(另外，我想说的是)，我们大家是不是还忽略一些东西?是不是也没有把关注点放到正确的事情上?(假如你遇到这些事情)，你会怎么做? doc的定位：(其实我们可以把它看作)是一份关于(如何设立)目标、如何分清轻重缓急、如何与开发者共事以及如何为开发者服务的(公开)清单而已。如果你愿意的话，完全可以把它称之为和web开发者相关的那些事。 (要记住)，web是属于所有人。(为啥酱紫说呢，有什么依据吗)?就拿web这种媒介来说，也正是因为触网(译者注：接触网络的简称)，对于我们来说不怎么费劲(incredibly low friction)，这才让web能够以迅雷不及掩耳盗铃之势的速度来到我们身边，而且在历史的长河中(in the history of the world)，我也从来没见过一个人就能够让web成为世界各地的人发布内容、吸收(consume )信息和经验的媒介。 我们的目标，是帮助开发者构建自己的开放平台，从而来满足用户的需求，然后就是让这个世界的信息以及经验都能够唾手可得。 我们一直在提醒(advocate for)自己，(自己所在的)Chrome 团队代表的是开放的web(精神)，并且希望web用户能够和我们一起来维护(support)web生态系统，从而让web生态系统，在不用顾及开发者究竟是使用哪种浏览器、工具或者用户更偏向哪个平台的前提下，达到更远大的目标。当然，我们也会通过一些方式来支持目标的实现，例如写一些辅助指南以及造一些成功的轮子。 (其实)我们更喜欢在一种开放的环境下工作，比如，我们力图让所有的开发者都能以更加透明的方式来实现自己的目标，那究竟啥是透明的方式?那就是直接与开发者合作。 我们不但是开发者的忠实拥护者，而且有时候还会去倾听来自开发者社区的声音(feedback)。为啥呢?因为这些声音，可以很好的协助我们把Chrome团队的重心(contribution)给引到web platform上去。 我们始终相信，web 是为所有人准备的，而且从(长远的 )web 健壮性的角度来看，开发者很有必要去关注一些针对页面可访问性、页面载入速度、安全性、易用性以及性能优化等方面的规则。 页面的可访问性 (大家都知道)，web已经以迅雷不及掩耳盗铃之势的速度来到了我们身边，这也就意味着，在不考虑性能(capability)的前提下，任何人或者应该这样说所有的人都能够使用web技术。 接下来，我们也会做一些(前期)工作，来确保能够让开发者明白，为啥他们需要构建可访问性的站点以及告诉他们应该如何构建(具有)页面可访问性的站点。当然，我们也会造一些轮子，来确保让开发者能够拥有完善的工具链，从而简化开发流程。 页面的载入速度 web的优势在于其获取内容的能力，举个栗子，单点一个链接，就能够轻松浏览到app里面的内容以及游戏里面的内容。虽说，在用户点击(某个)链接的过程中，有时候也会出现上述内容访问不到的情况，(不过，我觉得)内容访问不到的这个锅不应该由用户来背，这是因为，与开发者相比，用户的设备以及网络连接情况不知道差哪去啦。 我们希望看到的是，每个(站点的)页面都能够秒开，甚至是在网络极度不好的情况下，也能够达到上述效果。其次我们希望，网站的用户体验也能够做的更加流畅。(最后补充一句)，用户体验的建设，也不忘记把设备的电量、性能、所处的网络环境以及其它跟用户开销相关的因素考虑进去。 将来我们也会做一些准备工作，来告诉开发者他们应该往哪个方向使劲(there are clear goals and targets for all developers to aim for)，而且一般来说，开发者都会用执行速度快的工具以及库，那也就是说，让页面实现秒开的想法是站得住脚的( the reason for reaching these goals is rational and well understood)。 安全性 从安全性的角度来讲，web其实是用户的死对头。为啥呢?这是因为，对于开发者来说，开发一个钓鱼网站真的不是什么难事。所以，用户只有在确保该网站不会存在追踪用户、监控用户或者主动攻击用户的情况下，才可以信任该网站。 我们希望看到的是，在网络不好的条件下或者在用户使用外网服务的过程中，该用户仍然能够处于安全状态。 将来，我们也会帮助开发者来构建出属于自己的安全站点以及软件，最常见的套路，参考最佳实践指南、使用一些已经造好的轮子，然后就是(积极)参与生态圈周边(的建设)。 隐私 从隐私的角度来讲，web其实也是用户的死对头。所以说，只有在确保该网站不会存在追踪用户、监控用户或者丢失用户数据的情况下，用户才可以信任该网站。 我们希望，用户自己不但能够理解他们是如何与网站进行交互的以及(他们)是如何使用网站服务的等细节，而且还能够有选择性的将(自己使用过的)网站添加到可以信任的网站列表当中，最后就是能够认识到这些事情背后的深层含义以及权衡利弊(trade-offs and implications)。 我们也会给出最佳实践以及针对最佳实践的手册，(可能有人会说，为啥要给出这些东西呢?我们做这么多的事)，还不是为了让开发者知道如何来打造极致的用户体验，(那么问题来了，啥是极致的用户体验呢)?简单来讲就是，在用户看第一眼的时候，就能够让用户产生心理预期，而不需要用户主动降低自己的心理预期(users trust without the need to revert to “dark patterns” that erode trust)。针对上面提到的这些，我们也会做一些准备工作，确保开发者能够意识到这些数据(指的是由他们自己收集或者他们自己分析得出的数据)背后的深层含义，然后就是对一些必要的事情实行严格审查机制。 易用性 对于能够触网的人们来说，web真的是一种最简单、有效的方式啦。然而，(悲催的是)，web的构建过程，(对于大多数人来说)，真的有点过于复杂。 所以，在保证 web 构建简单易用的同时，我们希望也能够推动 web platform 的发展。另外，我们也会给 web platform 集成一些功能强大、且容易被开发者接受的新特性。 以后，我们也会说到，其实web platform一开始就是奔着打造web最佳实践以及造轮子的目的去的，另外，我们也会携手开源库的作者，来一起支持一些框架周边生态的建设。 性能 对于原生platform来说，web platform不失为一套可行的解决方案，不过令人遗憾的是，在跨浏览器以及移动设备的过程中，(对web platform的)支持度让web platform难以落地(make it hard for this to be a reality)。 我们希望看的是，(多年下来所积累的web)经验都能够分享给其他所有人，而不是把这些web经验给烂死在app 以及其它的封闭平台里面。同时，我也希望用户以及开发者都能够明白web究竟能用来干啥，然后就是知道如何把(丰富的web)经验给迁移到一些媒介的选择上去。 在尊重用户设备兼容性以及各家浏览器兼容性的前提下，我们也会造一些轮子以及写一些最佳实践指南，来方便开发者上手体验(web platform 的)新功能。(我再补充一句，我们推荐开发者使用 web platform 这些新功能的初衷)，真不是为了从火力上压制 native platform，(而且就算是没有 web platform 这些新功能)，开发者也还是会通过一种对用户、对自己友好的方式，把前沿技术给整合进去的( It’s not a race to match native, developers will be able to clearly see a path to integrating leading edge technology in a way that is good for their users and their themselves)。

本帖最后由 yd_猿 于 2018-2-26 16:52 编辑Web 性能优化是一个老生常谈的话题，也是前端页面开发十分重要的部分。当页面加载速度越慢，用户流失的概率就越大，性能和交互直接影响用户体验。 下面推荐几款 Web 性能优化辅助工具推荐，希望能对大家有所帮助。 Lighthouse Lighthouse 是 Google 开源的一个自动化工具，用于改进网络应用的质量。你可以将其作为一个 Chrome 扩展程序运行，或从命令行运行。 当为 Lighthouse 提供一个要审查的网址，它将针对此页面运行一连串的测试，然后生成一个有关页面性能的报告。可以参考失败的测试，看看可以采取哪些措施来改进应用。 Chrom 扩展则会把报告以非常人性化的图形界面展示给你。 11228 传送门：www.oschina.net/p/lighthouse Speed Racer SpeedRacer 是一款性能测试工具，它在 Chrome 中运行脚本，并生成详细的性能报告。 SpeedRacer 是直接借助浏览器来实际测试性能的工具，在实际工作中，可以与其它模拟用户访问流量来评估性能的工具配合使用。 11229 传送门：https://github.com/speedracer/speedracer Yellow Lab Tools Yellow Lab Tools 是一款 Web 性能及前端质量测试工具。与其他工具不同的是，它有一些在其他工具上无法看到的独特功能，例如页面加载时 JavaScript 与 DOM 互动和其他程序代码验证问题。 Yellow Lab Tools 偏向于一个发现不良实践的工具，会综合页面权重、请求数、DOM、错误的 Javascript、错误的 CSS 等方面取得一个评分。并显示出在加载页面的过程中，DOM 是如何相互影响。 11230 传送门：https://yellowlab.tools/ Web Tracing Framework Web Tracing Framework 也是 Google 推出的一组用于跟踪和调查复杂 Web 应用的库、工具和可视化工具合集。它可以帮助发现性能问题，跟踪回归，并构建流畅的 60fps Web 应用。能让你花更少时间来测试代码即可。 11231 传送门：www.oschina.net/p/tracing-framework grunt-perfbudget grunt-perfbudget 是一款用于评估性能的 Grunt task，它使用 WebPagetest 的公有或私有实例在特定的 URL 进行测试，并将测试结果和你预期的性能期望做比较。 如果小于预期，那么这个 task 就顺利完成了，如果超过了预期的性能期望，那么就会报告失败，并帮助你分析超出预期的原因。 11232 传送门：https://github.com/tkadlec/grunt-perfbudget Sitespeed.io Sitespeed.io 是一组基于最佳实践以及一些加载时序等量化标准的开源工具，用以帮助开发者分析网页的加载速度和渲染性能。 Sitespeed.io 从开发者的站点收集多个页面的数据，并根据最佳实践等规则来分析这些网页，然后将结果以 HTML 的形式输出，或者以数值的形式发送到 Graphite 。 11233 传送门：https://www-origin.sitespeed.io/

做前端架构师，需要精通哪些前端和后台技术。想听听各位大神的意见

本帖最后由 DevCloud 于 2018-3-13 16:09 编辑本文将向大家演示如何在JavaWeb项目中集成Springfox-Swagger-UI。 一．相关信息 Swagger-UI简介10367 Swagger 是一个规范和完整的框架，用于生成、描述、调用和可视化 RESTful 风格的 Web 服务。总体目标是使客户端和文件系统作为服务器以同样的速度来更新。文件的方法，参数和模型紧密集成到服务器端的代码，允许API来始终保持同步。 Swagger UI是纯static的web程序，仅仅在页面加载的时候，调用http连接，获取yaml字符串或者json字符串, 将yaml文件和放到静态项目中，直观的显示接口信息。 二．集成步骤示例 1.添加SpringFox-Swagger的相关依赖 在项目中添加SpringFox-Swagger依赖，只需要在项目的pom.xml中添加如下代码即可： 10368其中jackson-databind是负责Json和Java对象之间的转化，SpringFox是负责swagger接口显示。 2.引入swagger相关Jar包文件 找到项目的springMvc.xml，在项目中引入swagger相关资源，代码操作如下： 10369 3.创建swaggerConfig文件 经过上述两步操作，我们已经可以使用swagger的相关注解。这时候，我们需要定义一个Config.java文件，这个文件的作用是定义接口页面（Swagger-ui.html）的一些重要信息。 10370上图两处红框位置，第一个红框：@注解来启用Swagger2。第二个红框： swagger-ui页面，导出json文件的地址。 定义好的Config.java文件也要添加到SpringMvc中（扫描到即可）。 4.添加@Api注解 经过上述三步操作，swagger-ui.html页面已经可以显示一些信息，但是因为我们没有通过Swagger指定接口，Swagger-ui.html页面是空白的。 想要显示接口信息，我们还要借助@Api以及其他以@Api开头的注解。 10371 @RestController表示Controller的返回方式 ，@RequestMapping 表示该Controller的请求路径，@Api 表示 这个接口在Swagger-ui中的请求路径Tags 中文名称。 前两个注解是ssm项目基本具备的，集成Swagger只需要添加@Api注解。 我们还给这个Controller中的每个方法增加了@ApiOperation注解。@RequestMapping中的method代表这个接口的请求类型，共四类：Get、post、put、delete@ApiOperation是对这个接口的描述：Value值是接口在swagger-ui中显示的信息。@ApiResponses 代表对返回值的处理。如图：如果返回405 提示：参数错误，返回其他，沿用系统默认提示。 至此，SpringFox-Swagger就集成成功了。 三．从项目中导出json项目部署成功后，在验证路径后面加上/swagger-ui.html 即可访问项目的swagger-ui（ 114.115.137.228 是云主机地址）。在swagger-ui中可以看到各接口的详细信息。右键“右键另存为json”，保存链接即可获得接口测试的脚本模板。 10372

本帖最后由 TOM666 于 2018-1-8 16:44 编辑1.前言 2017悄然过去，2018已经来到。人在进步，技术在发展。2018年前端有哪些领域，技术值得关注，哪些技术会兴起，哪些技术会没落。下面就我个人的判断进行一个预测判断，希望能对大家起到一个参考作用!下面提及的技术，只是建议大家关注，也不是建议大家全部的都要学，而是建议大家按需学，自己觉得哪些需要学，对哪些有兴趣就学哪些!如果大家有什么工具，框架，库觉得可以推荐的，欢迎在评论区提点，让大家相互进步，学习! 2.PWA PWA(Progressive Web Apps)由谷歌提出，用前沿的技术开发，让网页使用如同App般的体验的一系列方案。明确的一点就是：PWA就是一个网页, 可以通过前沿的技术开发出一个网页应用。 自从谷歌提出PWA后，就持续的获得了业界的关注，热度可见一斑。就在今年，谷歌也宣布： PWA将获得与安卓原生应用同等的待遇与权限 。这就意味着以后的网页基本和APP将越发将近，那么关注度将会进一步的上升。 资料参考： PWA 入门: 写个非常简单的 PWA 页面 【转载】你的首个 Progressive Web App 【转载】下一代Web应用模型：Progressive Web App 3.typeScript TypeScript由微软开发。它是JavaScript的一个超集，自由和开源的编程语言。在这个语言中，添加了可选的静态类型和基于类的面向对象编程。由下图说明typeScript和JavaScript的关系! angular已经开始使用typeScript进行开发，react和vue也进一步加深对typeScript的支持。不难发现，typeScript的火热程度! 资料参考： TypeScript官方文档 TypeScript 资源集 从 JavaScript 到 TypeScript 1 - 什么是 TypeScript (看了第一篇，别落下这个系列的几篇文章) 4.parcel能给webpack带来多大的威胁 webpack 大家都知道是JavaScript模块打包工具，简单的来说就是把各个模块就行分析，编译，打包等，使产出的文件可以在浏览器中运行。 webpack的工作虽然是模块打包工具，但也能代替类似gulp等自动构建工具的部分功能!经过2017的发展，webpack的火热程度也是有目共睹。 但是，但是。在2017末就出现了一个黑马： parcel 。parcel出乎了大多数人的意料，也算是2017的最大惊喜之一。说到parcel的最大优势，貌似就是webpack的最大劣势：配置和性能!parcel号称零配置，多核打包，并且使用文件缓存，在时间上比webpack快了将近10倍! 从star上面而言，Parcel的关注度似乎超过了当时了webpack，热度仍在持续。 webpack难用之处，我觉得就是配置繁琐，且文档不完善，看着也懵逼。至于打包时间方面，只能说没有对比就没有伤害吧。如果Parcel能做好这几点，说不准能从webpack里面分到不少肉。 宣布 Parcel：一个快速，零配置的 Web 应用打包工具 Parcel Vs Webpack 5.WebAssembly 由谷歌, 微软, Mozilla，苹果等公司合作的一个面向Web的通用二进制和文本格式的项目。 引用腾讯IVWEB团队的说法：WebAssembly是一种新的字节码格式。它的缩写是".wasm"，.wasm 为文件名后缀，是一种新的底层安全的二进制语法。。它被定义为“精简、加载时间短的格式和执行模型”，并且被设计为Web 多编程语言目标文件格式。这意味着浏览器端的性能会得到极大提升，它也使得我们能够实现一个底层构建模块的集合，例如，强类型和块级作用域。 WebAssembly刚出来的时候，甚至有开发者猜想，以后会不会是WebAssembly代替JavaScript。在这里，我的感觉就是JavaScript不会被WebAssembly代替，等待没落，而是和WebAssembly共存的关系!2017年，chrome，火狐，IE，Safari四个浏览器统一通过了WebAssembly的方案，这是很少见的情况，我所了解的是第一次出现这样的统一情况，可见四个浏览器厂商对WebAssembly的重视。至于2018年，WebAssembly会有如何的发展，这个难说，初步预测应该还是普及推广，但是还没有到普及开发使用的阶段。但是无论如果，这个都值得关注! 来谈谈 WebAssembly 是个啥?为何说它会影响每一个 Web 开发者? WebAssembly 实践：如何写代码

本帖最后由 coding 于 2017-12-28 11:10 编辑JavaScript 是 web 开发语言。看看网上点击量超过 1000 万受欢迎的网页，将近 95% 的是用 JavaScript 开发的。 我们再来看 2018 最具就业前景的 7 大编程语言。JavaScript 位居第三。 7795像谷歌，火狐和 IE 等浏览器都支持 JavaScript 语言。所以，你决定现在学习这门语言，你可以很容易找到工作。但是事物都有两面性，也有人反对这种语言的学习。而且这与 JavaScript 语言本身没有太大的关系：是因为有这么多的 JavaScript 框架，初学者不用学习基本的 JavaScript 编程语言，直接学习如何实现框架就行。 框架非常棒，因为它们提供了随时可用的易于阅读和调试的代码。但是，由于这些框架提供了一个更简单的方法来将代码放在一起，新手程序员不能将 JavaScript 的基础学的扎实，让那些经验丰富的开发人员感到恼火。 在美国，JavaScript 开发者的平均工资是 72,500 美元，而经验丰富的开发者可以轻松赚取超过 10 万美元的年薪。 什么是 JavaScript，是什么让它这么受欢迎? 要了解为什么 JavaScript 变得如此受欢迎，我们首先要看看另外两个紧密相关的 Web 语言，即 HTML 和CSS。 HTML 让浏览器渲染什么样的内容。是文本，连接还是视频?都是 HTML 负责渲染的。 另外，CSS 则是为网页添加颜色和样式的。如果 HTML 是网页的骨架，那么 CSS 就是让 HTML 看起来更加自然的肉体和皮肤。 但是，虽然 HTML 和 CSS 都适合构建和设计一个网页，它们不能让网页动态的显示。比如用户填写表单或者点击一个选项的时候，这个请求就会被发送至服务器，页面会重新刷新。这就是 JavaScript 所做的。 JavaScript 使网页活跃起来。发布状态更新时，网页无需重新加载。用户发送的所有请求都在自己的计算机上处理。 这就是 JavaScript 如此受欢迎的原因，这就是 JavaScript 值得前端开发人员学习的原因。 它支持客户端处理，减少了服务器端的负载，大大提高了处理事务能力。此外，它还支持动画的渲染，可以使网页更加生动。 JavaScript 还值得学习吗? 这是必然的， 只要有人和网站互动，前端开发人员的对 JavaScript 需求就会一直存在。 虽然像 WordPress 和 Joomla 这样的内容管理系统(CMS)很受欢迎，但它们不会让 JavaScript 过时。 当然，Google，微软，Firefox和其他浏览器正试图想出更好的技术来取代 JavaScript，但是 JavaScript 很难在短时间内被取代。 因为 JavaScript 不仅可以对用户行为做出响应，而且也是编写跨平台应用程序的好语言。随着 Node.js 的出现，程序员现在可以编写复杂的服务器端代码。 这里有一些实用的方法可以让你的 JavaScript 知识得到很好的使用： 可以创建交互式表单来检测用户输入内容时是否有错误 可以创建一个搜索框，以响应网站上的用户查询(如Google) 可以创建需要不断更新的信息(例如公司股票价格或倒数计时器)的网页 可以将HTML每个元素准确定位到您想要的位置; 就像定位菜单项或图像一样。 可以纯粹为了娱乐而使用 JavaScript，或者添加流畅的动画，使网页更加高级和专业。 而且你可以肯定，大多数大公司不会很快使用 WordPress。而且，JavaScript 及其框架具有无与伦比的灵活性。 但这并不是说 JavaScript 没有缺点。JavaScript 最大的问题就是其安全性。一旦页面重新加载，这些脚本就会不经过用户许可就运行。虽然这是一件好事，但在许多情况下，可能会导致您的 Web 浏览器崩溃。而不用 JavaScript 是不可行的，因为许多重要的网站，包括谷歌，Facebook 和 Quora 不能没有 JavaScript而运行，至少现在不能没有 JavaScript 。 在 2018 年及以后学习 JavaScript JavaScript 是一个非常有趣，多功能和重要的 web 开发语言，它可以让网站变得更加活跃。不仅如此，它还很容易学习，越深入了解它，就会越多地了解它的所有惊人的创造性。 你可以创建网页游戏，创建跨平台的应用程序，甚至建立令人难以置信互动网站。 另外，学习了这门技能意味着你多了一个选择—做一个朝九晚五的的自由职业者，编程可以在任何地方进行。许多软件公司可以远程工作，可以拥有高新和其他的福利。 如果你对自己的工作充满激情，对工作有真正的兴趣。这样的话，在 2018 年学习 JavaScript 并成为前端开发者还是不错的。 来自：thenextweb

本帖最后由 mosquitoflying 于 2017-11-26 22:31 编辑javaweb容器传统的业务系统代码调用api的方式都是blocking的，这样方便开发和维护。但是一旦并发的业务急剧增加，这IO种方式就非常被动。因为一般请求从接收到执行完毕，都会占用一个线程，即使在IO阻塞的时候，都不会释放线程资源。一个线程本身占用的内存就接近1M，加上业务逻辑中分配的内存，线程资源消耗实际上是非常高的。当处理高并发业务的时候，就需要远多于cpu核数的线程数在支撑。这些线程本身的调度就很成问题。那么是否有必要使用异步化方式来改造当前的业务逻辑呢？最近项目中需要评估异步化带来的收益。做了一个简单的对比测试。尝试使用异步servlet的方式，改造同步servlet。同步的时候我们增加前端接收线程数到4000，异步的时候保持前端接入线程数为256，而内部处理线程为1024.令我们感到奇怪的是，增加线程的方式反而效果更好，8K小对象平均性能要高7%左右。为什么异步版本比同步版本性能还下降了呢？ 性能分析 我们进行了时间采样分析，发现了一些现象。 1、业务逻辑内部的阻塞式调用的接口延迟增大了。 以前访问数据库的调用的时间大约是25ms，现在增加到大约40ms+。 2、异步版本波动较大，总体平均下来，性能要差一些。 3、虽然使用异步的servlet，但是前端的业务逻辑传递到异步servlet之后，实际上还是需要下层的业务线程池继续处理的。那么必然增加了一次线程切换的开销。因此我们没有观察到高并发压力下，cpu context switch的明显变化。 那么是否说明异步化改造没有收益呢？其实不然。 异步化改造带来的好处主要有3点 1、减少线程切换 2、将前端压力尽快传导到后端 3、减少资源开销 我们目前异步化改造实际上以上3点都没有做到。特别是内部任然存在blocking的位置，而且往往blocking的位置在高并发压力时性能还会下降。 因此需要进一步优化，将业务内部所有blocking的位置全部打通，保证在这些点上不会随着并发压力增加非线性的增加，这样预计异步化改造必然会收益。 （我们在mock环境中做了一个测试，将系统中可以blocking的位置进行异步化改造，最终对比得到完全异步化之后大约有40%的性能提升。）

本帖最后由 小白 于 2017-11-13 15:31 编辑46284632

本帖最后由 小白 于 2017-11-8 12:00 编辑虚拟补丁（VP）近年来一直是保护应用程序最受欢迎的方法之一，如果在Web应用程序防火墙层级添加VP功能，该功能可用于保护Web应用程序免遭已知漏洞的威胁攻击。简而言之，VP利用静态应用程序安全测试（SAST）的结果并使用它们来创建规则以用来过滤WAF上的HTTP请求。 但问题在于，SAST和WAF依赖于不同的应用程序模型和不同的决策方法。因此，目前可用的解决方案中没有一个能够将SAST与WAF完美的结合起来。SAST基于白盒模型，它采用公式方法来检测代码中的漏洞。然而，WAF将应用程序视为黑盒子，因此它使用启发式方式进行攻击检测。但是如果我们能让SAST和WAF完美的结合在一起使用，我们可以通过SAST获取有关应用程序内部结构的信息，并将这些信息提供给WAF，这样我们就可以以一种“优雅”的方式来检测网络攻击。传统VP[hr]一般地，在Web应用程序传统自动化虚拟修补方法中，我们需要向WAF提供SAST检测到的每个漏洞信息，这些信息包括：漏洞分类Web应用程序的脆弱点攻击所需的HTTP请求参数值构成攻击向量脆弱点参数的值脆弱点参数中可用于漏洞利用的一组字符或一个单词。一般地，我们可以通过定义某些函数来获取HTTP请求中的参数值，例如下面是一段易受XSS攻击的ASP.NET页面的代码片段：通过分析针对上面页面的攻击向量代码，我们可以生成一组攻击向量值的符号公式：{condition =“secret”⇒param∈{XSShtml-text}} ，其中XSShtml-text是TEXT上下文中用于XSS攻击的向量集合。在实际的应用场景中，WAF虚拟补丁的描述符可用于生成过滤规则，以阻止所有能够利用相关漏洞的HTTP请求。虽然这种做法肯定会导致某些攻击，但它有一些很大的缺点：为了表示任何给定的漏洞，SAST需要发现一个可能的攻击向量。 但为了确保能够真正消除一个漏洞，SAST有必要处理所有可能的攻击向量。但是SAST很难将这些信息传递给WAF，因为由于攻击向量语法的不规则性，矢量集不仅是无穷大的，甚至不能用正则表达式来表达。对于漏洞利用所需的其他请求参数的值也是如此。如果入侵点和脆弱执行点之间的攻击向量语法在其上下文中发生了变化，那么有关脆弱参数的信息将变得没有任何的价值。由于这些设计上的缺陷，对于SAST检测到的漏洞，VP技术不能针对其提供可能的攻击保护。尝试创建这种“全面的”流量过滤规则通常会阻止合法HTTP请求并中断Web应用程序的操作，下面让我们稍微修改漏洞的代码：与上一个例子的区别是：在对两个请求参数都做了Decode处理，针对该新代码的攻击向量公式如下所示：[size=1em]1[size=1em][size=1em]（CustomDecode condition）⊃“secret”⇒param∈（CustomDecode {XSShtml-text}）。静态分析会在相关计算流程图（ConfiG）节点中为自定义解码函数导出一个公式，以描述Base64-URL-Base64转换链，如下所示：[size=1em]1[size=1em][size=1em](FromBase64Str (UrlDecodeStr (FromBase64Str argument)))。 针对这样的公式，我们仍然有可能在其基础上构建一个漏洞，但是由于以下原因，生成虚拟补丁的方法不能应用于此：只有当请求中的“condition”参数包含“secret”子字符串时，才可能利用此漏洞。 然而，该参数的值集是非常大的，并且由于解码功能的不规则性，通过正则表达式表达该集合是不可行的。事实上，攻击向量的请求参数也被解码。因此，SAST无法将该组危险元素描述为WAF。由于传统VP的所有问题都源于无法与基于白盒方法的WAF级别的应用程序进行交互，因此明显的解决方案是实现此功能并进一步改进，以便：SAST向WAF提供有关易受攻击的参数以及从进入点到易受攻击的执行点这整个过程中对攻击变量所做的所有转换信息。对于攻击检测，启发式方法被公式方法所替换，并且包含任何漏洞的利用条件信息。因此，运行时虚拟补丁应运而生。运行时虚拟补丁[hr]运行时虚拟修补（RVP）的原理是基于PT应用检查器（PT AI）中的计算流程图模型实现的。与公式符号计算的语义表示类似，该模型是使用应用程序代码的抽象解释构建出来的，模型中的图节点包含了目标语言的生成公式，并且公式产生与相关执行点上的所有数据流相关联的所有合法值的集合，具体如下图所示：上图中的这些流被称为执行点参数。 由于CompFG是可评估的，因此我们可以根据输入参数的值，在任何执行点上计算所有参数的值。 通常情况下，RVP分为部署（D）和运行（R）两个阶段，这俩个阶段分别对应于应用程序生命周期，具体如下图所示：部署阶段[hr]在部署新版本的应用程序之前，应用程序由PT AI分析，并且为那些易受攻击的执行点中的每个CompFG节点计算三个公式：获取脆弱执行点的条件获取其所有参数值的条件所有参数及其相应语法的值集上述中的所有公式集都将按照应用程序的入口点进行分组，入口点定义于分析器的数据库中，并和PT AI支持的每个Web框架相关联。通过提取包含的漏洞信息以及从代码（基于S-expression语法的特殊语言编写的代码，编程语言使用不依赖于目标语言的形式来描述CompFG公式）中提取相关的公式列表形成一份报告，例如上述代码示例中描述脆弱点参数值的公式如下：[size=1em]1[size=1em][size=1em](+ (+ "Parameter value is `" (FromBase64Str (UrlDecodeStr (FromBase64Str (GetParameterData (param)))))) "`")获取脆弱点的公式是：[size=1em]1[size=1em][size=1em]（Contains（FromBase64Str（UrlDecodeStr（FromBase64Str（GetParameterData（condition）））））“secret”）。 然后将报告被上传到PT应用防火墙 （PT AF），在报告的基础上，PT WAF生成二进制模块，该模块可以计算报表中包含的所有公式。 例如，用于计算达到上述脆弱点的条件的反编译代码如下：为了对公式进行计算操作，PT AF必须具有以下条件之一：预先计算可能在报告中出现的所有函数具有沙箱运行环境，用于运行Web应用程序或其他平台（如CLR，JVM或PHP，Python或Ruby解释器）以及应用程序中使用的库第一种方法在一定程度上能够保证速度很快，但WAF开发人员需要大量的手动工作来描述预计算数据库，即使开发人员将范围限制为标准库函数。第二种方法允许计算报告中可能出现的所有函数，但这种方法会增加处理每个HTTP请求所需的时间，因为WAF需要访问运行时环境来对每个函数执行计算操作。这里最合适的解决方案是使用第一种方法进行最常见函数的计算，而对其余函数使用第二种方法。公式中很可能会包含分析器无法处理的函数或者PT AF无法计算的函数，这些函数在公式中会被标记为“unknown”，并以如下所述的特殊方式进行处理。运行阶段[hr]在运行阶段，WAF将每个HTTP请求的处理委托给二进制模块，该模块分析请求并检测Web应用程序中的相关入口点。为此，WAF会选择所有检测到的漏洞公式，然后以特定方式执行计算操作。首先，计算公式的两个条件为：1）到达脆弱点，2）获取其所有参数的值。 在每个公式中，变量用相关请求参数的值代替，之后计算公式值。 如果公式包含标记为“unknown”的表达式，则其处理如下：每个“unknown”标志通过公式表达式树自下而上扩展，直到找到布尔表达式。在公式中，这样的表达式会被布尔变量替换，以用来解决布尔可满足性问题。假设通过上一步骤生成了关于“unknown”的n个公式，那么计算每个公式的值。 如果至少有一个公式是可满足的，那么该假设也被认为是可以满足的。如果计算显示假设为假，那么即使所有请求参数都有危险的值，HTTP请求也无法将应用程序引导到易受攻击的点。在这种情况下，RVP只需向WAF的核心模块返回请求处理即可。如果攻击条件满足，那么WAF会计算脆弱点的参数值，使用的算法取决于分析点所属的漏洞等级。这些算法之间的相似之处是用于处理包含未知节点公式的逻辑：与假设公式不同，在计算时参数公式不会被计算，而是立即被传达给WAF。为了更好地理解这一点，我们现在将回顾一下用于检测注入攻击的最复杂的算法。检测注入攻击[hr]注入攻击通过将特定形成的输入数据传递给应用程序来执行恶意操作，当这些数据被“注入”到目标文本中（包括HTML, XML, JavaScript, SQL, URLs, 以及文件路径）时，文本中包含了应用程序逻辑不想要的句法结构。如果一个脆弱点属于这个攻击类，那么它的参数值是可以通过使用污点分析语义中抽象解释的增量计算来确定的。这种方法背后的思想是：从下到上分别计算每个表达式，同时获得每个步骤的计算结果、每个函数的语义以及传统污点检查的规则。例如，对于上述代码和以下HTTP请求参数：[size=1em]1[size=1em][size=1em]condition=YzJWamNtVjA%3d¶m=UEhOamNtbHdkRDVoYkdWeWRDZ3hLVHd2YzJOeWFYQjBQZyUzRCUzRA%3d%3d，将此算法应用于弱点参数的公式的结果如下（污染参数标记为红色）：然后根据脆弱点参数的语法对该值进行标记，如果任何污点的片段匹配多个令牌，那么就代表这是一次注入的攻击。一旦与当前入口点相关的所有漏洞的公式计算结束，请求处理将与检测结果一起传递给WAF的核心模块。RVP优点和具体功能[hr]与传统VP相比，这种基于代码分析的应用程序保护方法具有很大的优势：得益于上述公式方法以及所有中间转换的能力，传统VP的缺点得到了解决。公式方法也完全排除了假阳性的可能性，只要公式不包含未知节点对Web应用程序功能没有不利影响，因为保护是建立在应用程序的功能上，而不是简单地试图解决它们。为了测试该技术并确认其有效性，我们开发了一种用于PT应用程序检查器和PT应用程序防火墙的模块原型，实验结果表明大约十五个开源内容管理系统（CMS）的性能测试显示出很好的结果：使用RVP处理HTTP请求所需的时间与使用传统（启发式）WAF方法处理此类请求所需的时间相当。 Web应用程序的平均性能如下：对于那些非攻击的请求占比为0％对于那些非攻击请求，但会导致脆弱点的占比为6-10％对于那些是攻击请求的，且会导致脆弱点的占比为4-7％尽管与传统VP相比有明显优势，但RVP仍有几个概念上的缺点：不可能在WAF（包括文件资源，数据库和服务器环境）上计算包含来自外部源的数据公式。公式的质量直接取决于分析期间代码片段的质量（包括循环，递归和对外部库方法的调用）。为了描述预计算数据库中函数的语义，需要开发人员加入到其中，该描述过程很难自动化，且容易出现人为错误。然而，我们已经设法通过将一些RVP功能从应用程序中删除并使用RASP技术来缓解上述这些缺陷，该部分内容我们将会在新的文章中进行阐述，尽请期待吧~原文链接：http://blog.ptsecurity.com/2017/10/do-wafs-dream-of-static-analyzers.html

本帖最后由 yd_14752044 于 2017-11-2 14:23 编辑前几天看到这样的问题： 最近在看bootstrap，发现除了大一的时候看过的html+css,和一些js，JQuery之外，几乎没学什么关于前端的东西。偶尔了解过一些html5。想知道如果作为一个团队的前端负责人还需要学习哪些东西？发现bootstrap与.less有关，除了这个还有哪些是需要学习的？ 其实，一步一步地来。 CSS不能编程？用Less、Sass、Stylus、甚至直接用 Absurd，框架除了Bootstrap还有很多。JS写多了很麻烦？jQuery。移动开发？Zepto.js。结构不好？找框架，Backbone.js是MVC，AngularJS和Ember.js是MVVM，Twitter还弄了个事件驱动框架Flight。库多了要优化加载？RequireJS。 **代码质量成问题？**Jasmine、QUnit、Mocha做单元测试。各种浏览器都要测？用Karma。测试通过了部署还有问题？持续集成，用Travis CI。用户行为也要测？用Selenium 。样式测试还有 Viff 。觉得JS都够麻烦的？用CoffeeScript。 **想做动画？**Canvas或SVG还有CSS3帮忙，干掉Flash。SVG太难画？用Snap.svg。想开发游戏？用Canvas。自己写FPS太低？用框架，CreateJS.。2D太幼稚？three.js帮你用WebGL开发3D，还不够给力？asm.js让你在浏览器中拥有虚幻3引擎。 这一堆东西都要配置部署，麻烦，用Grunt，库太多？用Bower管理，项目开始要创建各种文件文件夹？用Yeoman。开源项目太多了，GitHub.上找，不会？学Git。顺便用Jekyll托管博客，不是吧还有Ruby这玩意…SASS也是Ruby写的，等等Sublime Text是Python写的，要写插件？也学一下。调试太难？用Chrome开发者工具，一堆API和功能。 光在电脑浏览器上跑不给力？移动开发HTML5，离开网络就渣了？HTML5离线应用。不如原生应用？用PhoneGap。想调用原生API？开发Firefox OS应用吧。浏览器应用也得会吧，Chrome Firefox都有自己的文档。接着是不是把后端甩了，自己来，装Node.js，所以还得学点服务器知识，想用npm管理node包？linux技巧shell神马的也得学。想前后端通吃？再看看http协议。Web精通了？node-webkit 让你可以写桌面程序了，继续学吧。 想学模块化开发？看看CommonJS和AMD规范。理解JS有偏差？看看ECMA-262，等等不知道什么时候第6版就要出了。浏览器各不相同，弄不清该怎么兼容？看看W3C标准，HTML写出来人看的懂，机器读不懂？要SEO，要支持残障人士？看HTML语义化，全会了但IE就是不支持？叫不出名字的浏览器尼玛连JS都不知道是啥？渐进增强。想一次把各种设备全搞定？响应式设计。 然后上面这些不过是一些讨巧的小技术。公司做什么业务的？了解一下行业信息。面向大众的产品？交互设计。美工不给力？UI设计。外包和咨询？设计模式、重构方法、算法、数据结构。知道软件工程吗？了解一下敏捷开发，或许还可以试试TDD、ATDD、BDD。 看了这么多东西，第一反应是不是求中文文档？学英语去吧。 这些也不过是我目前所能看到的一小部分，而且每段基本都是到了一个边界，并不是没得学了，而是继续学又是另一片天地。真心希望有人能帮我填补知识盲区。另外，我仅把一些知识点串起来，不全或不对的地方请见谅。 其实我一直都在说，我只是看这个问题是疑惑该学点什么，所以摆了些工具和框架。但我发现许多人都只记得“大牛”两个字，其实技术栈层面的前后端之分根本就很滑稽，无非是JavaScript和某某语言的区别罢了，对资源分配策略或者说思维的不同才是前后端之分的本质区别。如果没有领会到这一点的话，还是好好学技术，别管什么前端后端的了，项目需要你做web做页面，你就学前端再学点Java, Ruby, PHP之类的都可以。不要把前端这个概念当成懒得学其他技术的借口。未来JavaScript会变成相对浏览器来说的底层语言，开发者用各种各样语法的语言开发之后编译成JavaScript在浏览器上跑，如果还是只会前端三板斧，那注定被前端如火如荼的浪潮覆灭。TypeScript 相比CoffeeScript已经有了一些质变，还有类似Haskell语法的Elm, 加上webpack 的催化，这种趋势会越来越明显。