直接复制 frontend 改很难，耦合严重，涉及的变量特别多。

不过解决办法也简单，继续在 frontend 里写 mobile 手机业务，通过 nginx 转发你二级域名 m.yourdomain.com 的请求到 frontend 的子路由 /mobile/就行了。

牛仔裤那么重，穿了练肌肉吗，打篮球的运动裤穿穿好了

QQ 的锅吧，别的 App 显示知乎正常

工资瞎写，背调最多查学历，如果能查工资这种企业机密的话。。

分享就能得 1 毛？我写个自动分享机岂不是躺着赚钱？

原生的就行了

我是建议产品去了解下关系型数据库的 sql 语言，只有了解了数据关系是如何存储保存的，才能知道哪些需求实现起来复杂，哪些实现起来简单。

其实在工作交流上用 email 是最佳体验。

因为微信可以抢红包。。。。

MariaDB

赶紧去考公务员吧

最后作为一个写后端的，站在我的角度，

前端求你别用 jQuery 了，给我老实去用 3 大前端框架，前后端分离！别把锅甩给后端来背！以前老是碰到加班排查半天发现是傻逼前端的锅，现在前后端分离了，同样的接口安卓和苹果手机 app 接口没问题，那么肯定是前端的锅！

也别用你们写的垃圾前端来污染后端项目！ git 分支合并冲突你们自己去解决好了，别扯上我！

@realkenshinji 应该加上关键词是最新的主流，很多人肯定不是最新的主流浏览器，要兼容性考虑

还有 jQuery 自带的 ajax、deferred promise 等足够应对大部分需求，当然要工程化代码复用那么在当时只能用类似 requirejs 的东西，当然在当时为了工程化代码复用出现了些思路清奇的人，他们用 c 语言的 makefile 来合并需要的 js 给相应的页面，每个 url 地址配个 makefile 文件也是贼 6 的，23333

聊一下 jQuery。


jQuery 的爽点是操纵 dom 非常直接方便，比浏览器提供的 api 爽多了。

jQuery 不爽的地方在于.click() .on()事件的滥用，导致维护起来就找不到到底是哪个用户行为事件出发了函数，于是很久以前我就学当时亚马逊的做法，要监听处理点击事件等绝不用 jQuery 的.on()，而是通过 html 原生的 onclick=<显式的回调函数名>来处理。


mvvm 框架的优势在于能够通过数据绑定，把对界面的操作抽象成为对一般数据结构的处理，从而应对逻辑复杂的页面，这个角度上来说，其实这个 jQuery 也能做，因为从数据结构映射到 dom 界面用 jQuery 很简单，这个无非就是写个渲染函数进行 html 拼接而已；但从 dom 变动映射回数据结构就要手动写很多回调函数更新数据，每次更新完数据后重新调用之前的渲染函数一下，这种做法 jQuery 可以处理逻辑复杂的页面。

当然实际情况是不专业的前端工程师，根本没有数据结构概念，在处理 dom 变动映射回数据结构时，直接操作 dom 就完事了，这种应对小需求可以，稍微需求复杂点就凉了。

都一样，楼主只是没有本科学位证书而已，没什么问题

普通本科毕业一样也混的不咋地，

现在工作还不如考公务员。

其实都很苦逼

其实和 PHP 语法差不多，没什么难不难的