今天听前端同事说, 现在流行把业务放后端做,前端越简单越好. 大前端是两三年前比较流行?

• 資深大佬 : joyhub2140

  看情况吧，前端如果计算量太大，对移动设备不友好，可能造成设备发热大，风扇呼呼叫，体验差。

  如果只是鸡毛蒜皮的逻辑，随意。剪刀石头布都可以。

  另外，对原生客户端来说，不用说，肯定要把逻辑重心放在服务端，起码后端改逻辑不需要用户升级 app 。

• 資深大佬 : pushback

  看情况吧，减少流程性的接口肯定是要后端做的，
  前端凑数据要点逻辑，现在很多逻辑都是交互性的吧？（我不是前端不清楚)
  个人认为前端逻辑（指数据方面）过多，那后端挺不负责的

• 資深大佬 : victor

  看情况吧，减少后端的开发任务我一般都是这么跟领导吹的。
  把复杂计算放在前端，消耗的是用户的硬件设备和时间来做处理和计算，能给我们省服务器的成本。

• 資深大佬 : gdtdpt

  现在前端 spa 框架应用如果不做好架构规划，代码审核等约束，是很容易构建出以 mb 为单位的 bundle.js ，再加上很多公司内网的客户端(电脑浏览器)性能并不高，如果再使用 IE 打开，再 ajax 请求上千条数据，是很容易直接卡死的，用户体验非常不好。

  以上是我公司内部某个应用整改前的真实情况，这个应用后端开发总是想着只把数据给到前端就行，业务逻辑能让前端做的都让前端做，前端实在做不了的才会放到后端。
  整改前，没人觉得几 mb 的 bundle.js 有什么问题，用开发的用的电脑测试没觉得慢，直到有一天领导打开一个页面加载需要 30 多秒，领导强制要求整改。在没有专业前端技术主管的情况下，没有人知道应该怎么改、往哪个方向改，前端代码写得太自由，都揉在一起了，拆分也需要重新梳理需求，整个过程异常痛苦。

  相对来说，后端主要是用 Java 开发，强类型保证了代码不能乱写，逻辑至少是可读的，springboot 框架和 mvc 的代码结构深入 curd boy 心，结构清楚逻辑好梳理，光看代码就能看个大概，相比前端一个 ajax 如果不真正执行，返回什么数据我都不太清楚的情况好太多了。

  考虑到团队成员的能力差异、异常排查的难度、可能出现的坑的大小、帮别人填坑的难易程度等因素，如果我是项目管理，我也会要求逻辑代码放后端。

  对于服务端的开销问题，一般业务逻辑不太容易影响服务器性能，如果真的到了由业务逻辑影响服务器性能的时候，也应该好好审查一下后端代码或者逻辑是不是有问题，一般这种代码或者逻辑放到前端也不一定能顶得住(比如对大量数据做聚合)。

• 資深大佬 : wuwukai007

  划重点： 听前端同事说

• 資深大佬 : cassyfar

  大前端什么时候存在过。。。我工作 5 年没见到。

• 資深大佬 : Wincer

  是真的，因为前端逻辑比较多的话会让客户机 CPU 运转加速，造成电脑发热量多，加剧温室效应，一点不环保。（狗

• 資深大佬 : fhsan

  @cassyfar 都喊了五年以上了，

• 資深大佬 : mht

  我自己写前后端，我感觉论维护或者开发的话，还是后端把一些计算做好最简单，前端就是拿到数据展示下就行。

• 資深大佬 : ditel

  架构师在哪？接口规范在哪？交互体验在哪？随意的组合前端真的没有问题吗

• 資深大佬 : zpxshl

  @joyhub2140 1 逻辑放后端有个坏处，后端要不断兼容旧版客户端

• 資深大佬 : zjp

  大前端的重点不是统一 APP 端 Web 端吗…
  前端计算非常不可信，遇到过因为页面卡住而提交错数值的

• 資深大佬 : KuroNekoFan

  有的后端就是弱智，设计的傻逼接口不仅毫无意义还净给前端添麻烦，还美其名曰业务需求

• 資深大佬 : KuroNekoFan

  至于主贴的问题，主理解交互逻辑和业务逻辑的区别吗

• 資深大佬 : murmur

  业务肯定后端的，前端那不是白送给竞争对手，放前端也得加一堆混淆反调试

• 資深大佬 : ffw5b7

  大前端不是指 api 调用侠吗？面对应用开发，调底层服务接口

• 資深大佬 : ly1836

  作为一个后端，我是非常不信任前端来处理业务逻辑的。

• 資深大佬 : shyangs

  業務邏輯放前端, 那都被競爭對手看光了, 看你老闆覺不覺得業務邏輯是機密.

• 資深大佬 : w88975

  作为一个全栈来说，现在的软件开发，其实前端的工作量大于后端的
  说的直白一点，90%的后端，都是 crud，现有框架成熟的情况下，很容易就能产出需要的功能接口
  而前端不一样，即使同样的逻辑下，不同的业务有不同的展示方式，操作逻辑，这块虽然不难，但是是实实在在的工作量。
  当我自己一个人做完整的项目的时候，更倾向于把更多的业务放在后端去处理，前端就简单的展示，简单的交互操作，这样开发效率其实是很高的。
  当我只做前端的时候，我也更希望后端能够处理更多的东西。

  其实说白了，不管后端有多么瞧不起前端，即使你把前端看作切图仔，不配称为程序员，你也不得不承认，大多数情况下，一个业务，前端的工作量永远大于后端。

• 資深大佬 : zjsxwc

  就是本来前端的活，分出来给 nodejs 做中台，处理完数据后最后给后端。

• 資深大佬 : jingcoco

  。。。。。最近刚和后端怼了一下。然后领导各打 20 大板。互相妥协了一下。

• 資深大佬 : xylophone21

  前端搭个 nodejs，结束

• 資深大佬 : KuroNekoFan

  @w88975 实话

• 資深大佬 : u823tg

  所以前端加了一波薪后把活又扔到后端了

• 資深大佬 : Tink

  计算绝对要放到后端，放到前段等着别人 hack 呢

• 資深大佬 : gouflv

  前端说啥就是啥，你不懂有什么办法

• 資深大佬 : statement

  后端一把梭 css 样式都给了。不给前端添麻烦。 因为前端也是我

• 資深大佬 : ffxrqyzby

  我投后端处理一票

• 資深大佬 : ericgui

  我们公司是后端不给力，除了给数据，啥也不会
  前端被迫当场计算很多逻辑
  所以很慢

• 資深大佬 : jones2000

  现在 PC 和手机性能都很高（ GPU 直接就可以拿来计算）， 可以支持一些本地的计算，如果什么都放在后台算，就浪费了这些配置了。 只是现在大部分前端做算法的能力不行，只会一些 UI，　让前端做算法又慢又容易出错，还不如后台算好给前端。可以让后台直接把部分业务移植到ｊｓ上，给前端用。我开源过一个金融图形库和策略指标引擎都都前端计算的（ https://github.com/jones2000/HQChart ）。只要前端能力行，一样可以做很多后台的活。
  而后台ｊａｖａ，　ｃ＋＋等应该做一些业务计算模块，什么读写数据库的操作的体力活都给ｎｏｄｅｊｓ，ｐｙ的人来干，ｊａｖａ，ｃ＋＋直接做计算模块，提高计算效率，　对接ｎｏｄｅｊｓ，ｐｙ就可以。

• 資深大佬 : pabupa

  @statement 哈哈哈哈哈哈哈哈哈哈哈哈

• 資深大佬 : 594duck

  @cassyfar 吹 B 小业务的互联网公司人家就搞过的，还喊出了后端已死前端当立（就和十年前喊出测试已死，17 年开始喊运维死了一样）

  听他们吹牛逼永远很精彩 。

• 資深大佬 : H15018327040

  TM 的我这的后端只管查出数据，连简单的数据组合都不处理，搞得我一个页面无数个嵌套请求，通过返回的数据再次请求一次，页面加载数据就得好久。

• 資深大佬 : jzmws

  我的原则是前端只做展示 , 科学计算 (非涉及到钱的) 允许前端计算 其他都用后端计算

• 資深大佬 : Mutoo

  大后端 -> 大前端 -> 大中台

• 資深大佬 : demotu

  在有前后端开发的情况下 前端还是尽可能的简单吧 因为后端是服务端 一般都是可控的的 对于暴露出去的东西要尽可能简单 避免漏洞

• 資深大佬 : vone

  前端仔是说什么都贼有道理，开发什么都贼 TM 垃圾。

• 資深大佬 : tikazyq

  对全干工程师来说，怎么做都无所谓，给钱啥都可以

• 資深大佬 : NasirQ

  业务逻辑还是放后台靠谱，就现在这前端混淆加密，分分钟就抄走了….. 交互逻辑，页面展示，前端特效这些放前台来写。

• 資深大佬 : DT27

  前端还是老老实实处理交互展示吧，别再干后端的活了。。。

• 資深大佬 : hoyixi

  曾经流行业务都放前端吗？什么场景会把业务都放前端做呢
  我没怎么见过，前端基本都是处理交互，除了展示， 另外一个重要点就是对用户输入的过滤和验证。

• 資深大佬 : 1cming

  没想到 3L 还能有这么多点赞

• 資深大佬 : yaphets666

  要不说你不懂呢,我现在这个项目就是后端基本就负责 CRUD,数据处理前端来做,一个页面 20 多个请求发出去,请求回来的数据做参数再发 N 个请求.这种应用用户体验是极差的.会有很多 loading 动画.什么降低后端负载都是扯淡.8 核 16 线程的服务器,性能有你们说的那么不堪吗?组合点数据,处理处理数据就累着了?

• 資深大佬 : OHyn

  交互相关的逻辑也只能放前端。。。后端做好数据聚合就行，否则一个页面 N 个请求，PC 端还好，移动端，光 ajax 就好久。。

• 資深大佬 : jaylee4869

  我司前端就这样，连 node 也不会，只会 jquery 一把梭。都 2020 年了，难以置信。工资居然还比后端高。

• 資深大佬 : zppass

  从某种意义上说的不算错，前端尤其是 APP 你给整一堆业务逻辑，到时候有问题要修改急着上线怎么整，小程序也审核，IOS 也审核，应用商店也审核，客户不升级你咋整。后台逻辑修改就好多了，不变应万变。
  大前端实际上他能把那些第三方的服务弄好就够了，后端纯做一个数据库的搬用工，甚至连数据处理都不处理一下，也实在没啥意思。

• 資深大佬 : gollwang

  你们遇到过纯展示得前端么。。。真纯展示，数据不做任何处理，不做任何判断。。。

• 資深大佬 : fffang

  把整个架构体系抽象成 MVVM 的话，VM 这一次，也就是数据处理，最好在服务端处理。

• 資深大佬 : konakona

  你的这个看待整体选型的“方式”，其实十几年前就是这样做的，反而是 06 年左右 Reactjs 出现、Nodejs 的影响力、SPA 的市场需求逐步扩大后，才让前端圈迅速发展至今，尤其是出现 Taro 、uniapp 等全平台的框架，还有 GG 的 Flu，全面发展大前端的市场。

  因此，你的这个看待整体选型的“方式”，其实已经是过时的！

  首先要做技术选型，在确定有哪些技术问题要攻克，有哪些业务状态和业务前景，做好技术架构后，再看待这个问题。

• 資深大佬 : my1103

  @jaylee4869 还在用 jq 嘛，2020

• 資深大佬 : xgfan

  前几年流行，是因为前端开始做工程化，觉得可以承担一部分业务了，顺便可以加薪。
  这几年又把业务扔给后端，是因为发现业务一堆破事，工资已经涨上去了，破事当然后端做啊。

• 資深大佬 : winglight2016

  @cassyfar 20 年以前，C/S 流行的年代，还是流行过类似的“大前端”，虽然这个词我也是头一次听说。。。

• 資深大佬 : ETO

  说到这个我就很生气，我是搞 PHP 的，我提供后端接口给 java 后端，我说我数据都是总好几张表里汇总出来的不好做分页，一共也就几百条数据，你自己做个分页吧。java 说 做不了内存会爆掉，我说那行吧。那就让前端直接渲染吧，java 我也不懂，前端说单线程应用 不方便操作数据，做不了。java 我不懂，可 vue 连 几百条数据也渲染不了吗？

• 資深大佬 : Mazexal2

  @ETO 如果用户量少的话, 几百条数据当然没关系, 几万条数据直接返回也是有的, 不过用户量多了以后, 后端确实内存会爆掉的, 不过你们前端就是懒逼, 分页也就几行代码的事情, 也不想做

• 資深大佬 : di94sh

  @w88975 你是不是只吧撸码行数看进去了，业务流程梳理抽象，api 定义，性能优化，这些都不是工作量吗

• 資深大佬 : leega0

  我也是跟公司的后端这么说的，原因很简单，页面越静态越好，前端的本质是展示，不然直接丢个代码生成器给客户用不就行了。

• 資深大佬 : zjuster

  @victor 边缘计算！哈哈哈

• 資深大佬 : Chenamy2017

  @statement 每个公司都应该招像你一样的人才。从此社会和谐，江湖再无前后端之争

• 資深大佬 : Kusoku

  懒惰是程序员的美德哈哈

• 資深大佬 : iyu90

  什么业务？你们要用前端挖矿吗？现在都 2020 年了，不知道上面有些个后端仔，那来的优越感

• 資深大佬 : bojue

  @victor 你是个人才

• 資深大佬 : ihuguowei

  好多人对自己不了解的领域想当然，前后端都有……

• 主 資深大佬 : chaleaoch

  @KuroNekoFan 主不太理解…
  请教个具体问题.
  “`
  一个 resource 两个 field : a 和 b
  a = [‘open’,’closed’, ‘error’]
  b = [‘true’, ‘false’]

  api 设计成 <resource>/?a=open

  现在需求改了
  当 a == error
  返回
  a == error or (a == open & b==false) or (a == closed & b==false)

  a == open or a == closed 相应的改成
  a == open & b == true
  “`

  像这种情况, 你打算怎么处理
  我的建议是 前端请求两次 ajax 就齐活了.
  前端说,不, 应该后端改.

  这种属于业务逻辑吧?我觉得. 但是这接口有问题啊.
  至少也得改成
  <resource>/?type=a1
  <resource>/?type=a2
  <resource>/?type=a3
  类似这种

  是这个意思不?

• 資深大佬 : KuroNekoFan

  @chaleaoch 我觉得你这挺典型的，既然 a 和 b 决定了 resource，那就应该 resource?a=sa&b=sb
  把状态组合影射为一种 typecode，是典型搞笑行为

• 資深大佬 : oma1989

  然而好多快餐工，连最基本的 JS/CSS 都不懂，只会使用 VUE 或某个框架都号称是前端。。。。。。。
  （我们前端之调用 API 展示数据，null 后台处理掉， 日期格式后台处理好了， 展示小数位数后台处理好了）

  还是自己全干来的靠谱。。。。

• 資深大佬 : godgc

  我倾向于，复杂的计算逻辑放由后端处理，前端主攻用户体验层和简单的数据处理

• 資深大佬 : jake361

  举的那个例子，我是嫩是没看懂，可能是我太菜了。

• 資深大佬 : daxin01

  @jaylee4869 货物崇拜编程

• 資深大佬 : jake361

  @KuroNekoFan 反正我觉得让前端请求两次… 我觉得这句话就暴露了水平

• 資深大佬 : gdtdpt

  @chaleaoch 以我的开发习惯理解后端提供的接口是为业务服务的，不是为数据服务的，像你这里说的情况，之前这个业务是调用一个接口，但是现在业务逻辑变了，有两个解决方案
  1. 前端改为调两次不同接口，然后拼装业务需要的数据。
  2. 后端修改此接口的业务逻辑，增加参数判断逻辑。

  如果前端只是改所调用接口的 url，不增加调用次数的情况，我赞成前端改，因为有别的接口满足业务需要。
  但是需要前端改成调用多次接口并封装部分业务逻辑，我认为应该后端改，以我的开发习惯我会避免在前端写这种包含部分业务逻辑的代码。

  理由是今天这个业务从调用一次改成调用两次，可能过段时间业务需求又变了，就会变成调用三次，或者有其他的前端接口调用由一次也变成调用多次，这样出现什么问题到底是前端的问题还是后端的问题说不清楚，也不好排查，出现问题需要前端后端一起看数据和逻辑，浪费人力和时间。前后端职责模糊，也容易前后端互相推诿。

  说得难听点，如果后端只想做数据库中间件，不处理业务，那前端整一套 SSR 框架直连数据库就行了，要后端干什么。

• 資深大佬 : frankkai

  如果服务端接口服务于多种客户端：PC 、移动端、Native

  最好还是服务端统一做处理更好。一端处理，多端舒适。

• 資深大佬 : hxy91819

  主业做后端，也写过一点前端，我倾向于后端把数据整理好了，前端直接拿来显示就行了。后端做数据处理更容易。前端还需要处理样式和业务交互逻辑。但是一些简单的处理，前端可以自己做，比如时间，后端给时间戳就行了，具体什么格式显示，前端自己处理。

  另外，对于图片的处理（比如生成、编辑图片）这种只能客户端做，服务端做成本会很高（带宽、CPU 等）。

• 資深大佬 : leonardyang

  我只想知道，业务逻辑扔在前端，咋保证不被篡改啊，现在哪怕不是干这行的都会点打开 chrome 调试，按软件安全原则来说用户所有输入都不能信任，信任用户侧的业务代码运行结果就更过分了吧？

• 資深大佬 : hxy91819

  另外我建议所有后端都要学点前端，所有前端都要学点后端。免得被对方忽悠，有时候真的就只是同事想偷下懒而已。

• 資深大佬 : wangyzj

  前后端怎么分得看具体需求
  还有后端的数据复杂程度和分散程度
  不能说都给前端

• 資深大佬 : melvin

  复杂计算 还是放在后端好，前轻后重

• 資深大佬 : jaylee4869

  @daxin01 nb, 绝了，学习了。

• 資深大佬 : guanhui07

  觉得看情况把

• 資深大佬 : xzg1993

  @H15018327040 +10086 我这一个页面，六个接口请求

• 資深大佬 : H15018327040

  @xzg1993 最恶心的情况是有一个列表，每一项都有一个子对象，子对象上只有一个 ID，获取列表后还得循环去通过子对象的 ID 去获取子对象的数据然后组合成一条完成的数据，真 TM 日了。

• 資深大佬 : xzg1993

  @H15018327040 在说一个，一个请求 要给后台传一大串 json，后台在返回一大串 json，我自己去拼接自己想要的请求，有时候想要显示一个页面数据，还要请求这种垃圾接口 2 到 3 个。

• 資深大佬 : KuroNekoFan

  @jake361 请求多少次不是关键，关键是，type${x}作为一个由 a,b 衍生出来的值，可能性随着需求会越来越多，那么这里首先不应该把这部分逻辑放在前端，
  我还见过更 sb 的，不仅要带上衍生值，还要带上原始值，即 resource?type=typex&a=sa&b=sb

• 資深大佬 : H15018327040

  @xzg1993 有时候我就想，什么都不做处理的数据还不如做一个接口，前端直接传 SQL

• 資深大佬 : w88975

  @di94sh
  就目前 crud 那一套,现有框架成熟的不能再成熟了,除非你自己撸一套,否则根本就是一把梭
  业务抽象我就不说了,这个跟前后端没有太大的关系,这个是整个项目的架构决定的
  api 定义这个也能拿来说吗?这个也不是工作量导向的东西,主要靠约定俗成,也是纯架构方面的
  性能优化,这个就是仁者见仁,智者见智的东西了
  你所说的这些东西,都是作为一个后端必备的,不能说没有工作量,但就目前 90%互联网公司所涉及的业务来说,拿出来说真的不值一提

  我并没有站在一个纯前端的角度来讨论这个问题,我也是做了多年的后端,我很讨厌写前端,就是因为前端相对于后端来说,太杂了,没有像后端那么多年积累起来的标准库(近几年稍微好那么一点),同样的业务,前端的选择更多,工作量也更多.
  处理纯数据,和写用户交互的东西相比,还是纯数据处理起来更简单明了

  以前后端鄙视前端,那是因为前端真没啥技术含量,”切图仔”们只知道填数据,画页面,对数据来源以及数据的处理根本不用关心. 我不能说现在前端多有技术含量(也可能没有),但就事论事的话,工作量是特别大的.

  打个比方,写个修改用户资料的业务,后端只需要处理字段,校验字段,校验不通过返回什么,通过又是什么,然后更新 DB.
  前端首先要完成这个页面,然后再处理数据,例如头像要用什么组件东西展示,是否可修改,修改的话,得用哪个接口去上传图片,上传状态,各种提示,表单的校验等等,不说复杂不复杂,至少比起纯数据处理来说,是复杂的.

  就好比 V2EX 的回帖时间,后端只返回时间戳,前端要去判断: 大于 24 小时,展示完整年月日时分秒,小于 24 小时,展示 xx 小时前,这时候,后端要是直接返回这个时间,前端就能省很大一部分事,毕竟大多时候,前端也只是拿时间戳来做 format 成字符串,而不是做条件查询

• 資深大佬 : leejaen

  @w88975 同意，我公司做的某个大项目，前端 react，后端 java，人数分别是 6 和 40，我们前端累的要死，后端一个按钮的小功能拆 6 个人做，并且他们做完了就干等着我们，还经常告状：后端都做完了，就等前端了。技术总监那里要人不给、要时间不给，让我想办法，一帮后端天天摸鱼干吃饭。还可劲说自己这样忙那样忙，这种后端真是让人鄙视

• 資深大佬 : cco

  最近多了点前端和后端搞事情的帖子。
  我觉得还是得将注意力转移到语言上。PHP 是世界上最好的语言！

• 資深大佬 : cco

  @leejaen 我司曾经一群后端 996 呢。前端周末在陪妹子看电影，怎么说？

• 資深大佬 : zzzmh

  需要结合具体情况，例如一个表 1000 条数据，排序分页筛选，放后端做划算，如果全部给前端也能实现，但网速的开销过大，实际用到的太少，血亏。如果数据是一样多固定大小，那放在前端算，节约服务器算力，是可取的。

• 資深大佬 : littleFive

  @cco 听你这么一说，我就感觉你们项目不会是前后端分离的

• 資深大佬 : miniwade514

  大前端说的是 web 和 native 融合的事情，不是“代码体积很大的前端”。业务逻辑放哪儿，跟是不是大前端没什么关系。

• 資深大佬 : daxiongz

  @jaylee4869 咱公司叫啥？我也想去

• 資深大佬 : hoosin

  我觉得这个边界是，展示层面的。
  前端、中间层都可以做，反之还是后端来计算吧。

• 資深大佬 : kaiki

  能让后端做就让后端做，后端不会相信前端的任何逻辑的

• 資深大佬 : airplayxcom

  宣战贴 ，不做任何评论

• 資深大佬 : canxden

  前端后端 角度 X
  用户 角度 √

  并不是所有用户都会喜欢升级的. 如果很多业务要依靠前端升级版本来解决.
  为什么不尽可能多的功能可扩展, 而不必用户升级来解决呢.

  exp: 日期. 后台传时间戳 & 后台传日期字符串.
  万一哪天要展示逻辑改变, 是不是还要更新前端版本来解决这个问题?

  btw: 改不改都看产品心情. 前端后端要佛系. 手动狗头

• 資深大佬 : syyy

  去年让前端写个冒泡，把十个元素以内的数组排个序输出一下，然后隔天告诉我不写。我生生把返回的结果集翻到最深一层，取出属性值排序一遍丢出去。

• 資深大佬 : Sapp

  不把逻辑放在前端不是因为计算量，这个跟计算量也没有任何关系，有几个项目能大量吃资源的？
  不放前端是因为第一没有必要，很多东西设计安全之类的前端你就算走一遍流程，后端也还是要走，等于两个人都要搞，那你何必放前端？
  第二是因为前端毕竟是个页面，有 UI 要展示，你全都扔给前端，他还要协调数据和 UI，复杂度会成倍往上走，而你在后端做好，只需要关注数据，拼好发给前端就完事了，典型的就是有些后端会把一个接口拆成 n 个让前端互相调，这简直是坑爹操作，对于后端明明拼接一下数据很简单的事情，给前端做简直就是个折磨。
  最后就是现在很多后端的客户不只是前端，往往还有客户端甚至其他公司的客户之类乱七八糟，这种情况你把东西放在前端做其实也是个浪费，你的前端做一次移动端做一次客户还要做一次，如果涉及到校验的问题那更容易出问题，你的前端校验好了移动端没校验好，整个系统全都崩了。

• 資深大佬 : Ritr

  这种肯定是后端改啊，请求是异步的，通过两次请求来判断一个事情首先不合理，其次两次异步不方便处理，最后是增加了复杂度

• 資深大佬 : cco

  @littleFive 从 17 年开始就一直是前后端分离了~~~

• 資深大佬 : Solace202

  @victor 怪不得现在手机内存赶上电脑内存了。。。