公司搞了一个新项目,因为要 SEO 所以我打算用 React 上 SSR,但是公司的 Java 说完全没必要,非要我写 JSP,说这样简单一些...我实在无语,怼他们也没反应,不知道咋搞。
101
VoidChen 2019-01-09 11:48:56 +08:00
就等着翻页了!
|
102
royzxq 2019-01-09 11:49:09 +08:00
瑟瑟发抖,SSR 怎么又变成洪水猛兽了。 要用 jsp 可以啊, 你就丢过去静态模板让他自己自娱自乐
|
103
wuweijia 2019-01-09 11:53:42 +08:00
你以为你用 react 就万事大吉了?
|
104
gz911122 2019-01-09 11:57:56 +08:00
2019 年了还有吹用 jsp 的 你 tmd 用模板引擎也比这玩意强
上面还有个赞成的老菜鸡 怕不是还在用 jdk1.6 笑死我了 建议楼主让后端闭嘴,反正要不给给 html 他自己玩 jsp 去,要不就前端来做服务端渲染。 |
105
darknoll 2019-01-09 11:58:00 +08:00 2
领导说用啥就用啥,出了问题别人可以帮你。
你自己一意孤行,出了问题你等着天天加班吧。 |
107
deadEgg 2019-01-09 12:01:22 +08:00
我就比较好,啥都能接受
出发点还是要从项目考虑,不要为了杠而杠,争个你死我活只会增加戾气和没必要的认知。 前后端分离的好处是:1.职责清楚,分工明确 2. 业务开发明确 3.长期开发效率很高 单用 jsp 的是:1.直接可以做 seo 2. 短期内简单 3.简单 所以就事论事,只要 seo,页面不多,后面开发不重,我站 jsp。 我是一个全干,不为领域站队,恕我直言,单领域觉着牛逼的在我看来话语都没有价值。 |
108
pony279 2019-01-09 12:02:29 +08:00 1
4 楼正解
如果上了 react SSR, 就不仅仅是前端的问题了, 还有一堆附加工作量, 这可是已上线的生产环境, 不是在自己本地搭个测试服务器耍耍就完了, 这种架构变更, 你想上就上? |
109
ytll21 2019-01-09 12:02:46 +08:00 2
@mars0prince 现在的人都这么厉害了,主动踩坑,项目出了问题谁负责?辞职跑路了事?呵呵
|
110
darknoll 2019-01-09 12:03:27 +08:00
@gz911122 技术上没什么高下之分的,学什么不是学,现在 jsp 过时了,说不定一段时间后 react ssr 也过时了,做人圆滑点。
|
111
biossun 2019-01-09 12:04:16 +08:00
如果是简单的内容展示页面,没有什么前端交互,也没什么异步刷新,是可以用 jQuery 那一套啦。
不然的话,相比 jQuery,React 的整体效果是要好很多的。 |
112
duan602728596 2019-01-09 12:04:58 +08:00
可以啊,前端直接 gulp,切出来图给后端自己玩去,90%搞出来 ui 问题交互问题
|
113
biossun 2019-01-09 12:06:54 +08:00
当然,这也要权衡你们对浏览器兼容性的要求、时间节点的要求、以及你对 React 和 SSR 的了解程度等一些条件。
|
114
ranwu 2019-01-09 12:07:35 +08:00
公司想怎么来就怎么来了。
|
115
isbase 2019-01-09 12:09:01 +08:00 via Android
@ alexsunxl
有些人是真的蠢,自己是个彩笔,还喜欢在这里扯淡 性能,部署,监控,出了问题会调试(比如内存泄漏),这些问题你都能搞定就去做,SSR 带来的开发体验和效率是其他方案无法相比的 一般不用担心性能问题,极端情况还可以上缓存,但是不要用什么组件级的缓存 https://arkwright.github.io/scaling-react-server-side-rendering.html |
116
jiangnanyanyu 2019-01-09 12:09:44 +08:00 via Android
坚决不写 jsp,最少 fm
|
117
springmarker 2019-01-09 12:21:19 +08:00 via Android
看写什么东西了,管理系统的话上框架还是有必要的,要是就几个展示页面,以内容为主的话,用 jsp/freemarker 我觉得没有任何问题,ssr 那一套,要是出了问题跟个大黑盒子似的,楼主要是能搞定另说。
|
118
guorui112 2019-01-09 12:22:28 +08:00
jsp 好啊,省事,写好静态页面给后端,又不用掉接口啥的,而且数据问题跟你关系也不大了,
|
119
wangxiaoaer 2019-01-09 12:23:16 +08:00
@yhxx #5 你这是抬杠,java 应用里面 jsp 作为完全支持的一种技术方案,开箱即用,零部署,汇编能比吗?
前端不要觉得什么高大上就上什么,包括所谓的前后端分离,对传统应用来说一个 war 包搞定的就是最简单的。 我还看到过 java 后端接口,nodejs 中间包一层,前端 spa 这种方案,就特么 5-6 个页面,这么折腾也是服气,没有阿里的命,得了阿里的病。 |
120
hyyou2010 2019-01-09 12:25:03 +08:00
看过一下 SSR,感觉挺麻烦的,通用性不好,放弃了。
怀疑这是门短期临时技术,会很快被替代。 |
121
wangxiaoaer 2019-01-09 12:28:24 +08:00
@yhxx #68 别扯淡,大部分小规模公司的运维是后端承担的,你上所谓的 ssr,如果必要性 不足,那就是白白给人增加了部署 node 等一套环境的工作量。我是没见到过让前端去做运维的。
|
122
herozzm 2019-01-09 12:30:48 +08:00
lz 短视,运维怎么办,其他人接手怎么办,你搞起来容易,别人不一定
|
123
alexsunxl 2019-01-09 12:34:18 +08:00
|
124
dcatfly 2019-01-09 12:38:08 +08:00
我觉得中性项目还说 jsp 好的应该都不是前端工程师。或者说根本没有用现代框架写过上规模的前端代码。
|
125
happycloud 2019-01-09 12:47:26 +08:00
坐等第三页
|
126
alexsunxl 2019-01-09 12:48:58 +08:00
|
127
shadownet 2019-01-09 12:56:16 +08:00
没有深度了解 /使用一门技术前,不要随意 diss 人家
没有一门技术或者框架或者架构 , 随便你们怎么叫的东东是银弹,无数前辈的教训告诉我们,能用就好,追求各种新技术啥的都是徒劳的,浪费人力财力 |
128
oatiz 2019-01-09 13:04:22 +08:00
提倡用 jsp 的是半截身子入土了吗?
|
129
notreami 2019-01-09 13:05:49 +08:00 1
不就是技术选型,一边考虑持续维护、一边考虑持续发展而已。
方案也很简单嘛。先 jsp 之类的整起,后面自己申请完善了 react ssr 再重构不就可以了? 就这么个破问题,居然需要讨论。。。 |
130
xfriday 2019-01-09 13:07:35 +08:00
2018 还提倡 jsp 就是耻辱
|
131
gz911122 2019-01-09 13:08:44 +08:00 1
@darknoll 对 那为什么要学习一个已经过时 对自己职业生涯好多帮助的语言?
先表示,我是 java 后端 ,我自己都不想用这玩意,学习 jsp 对一个前端有什么帮助? 学学 ssr 下个工作怎么也能多涨点工资。jsp 能有啥帮助。怕不是简历都不好意思写上去。 |
132
gz911122 2019-01-09 13:10:58 +08:00
@herozzm 这有啥短视的。接手的人能多学点东西不好么,你接手一个东西肯定希望能从中学习到什么,
而不是接收一堆过时的东西,还需要维护。 至于对公司而言,那是公司的事,作为初期开发还是要以自身提升为主。在不影响开发进度的情况下,不需要考虑公司发展问题。毕竟公司是老板的,技术是自己的 |
133
laodao 2019-01-09 13:11:23 +08:00 1
问题核心是解决 seo 问题吧,
你以为用了 ssr 就能很好的解决 seo 问题了? 如果用 react,绝对不是加一个 ssr 就可以解决 seo 的,虽然可以后端渲染了,但是你为此要做很多类似 ssr 的技术去解决所带来的各种 seo 问题。 十年 SEO 经验,十年前端经验,我都不敢用 react 技术能很好的保证 seo。 |
134
gz911122 2019-01-09 13:11:26 +08:00
@wangxiaoaer 但是他从中学到了东西,一门技术 你不去用是永远无法掌握的
|
135
fcten 2019-01-09 13:11:48 +08:00 1
SSR 和后端有啥关系,后端不都只要提供接口吗,不比 JSP 简单得多?
当然,如果贵司的后端还兼职运维,那就建议不要折腾了。 |
136
igb 2019-01-09 13:13:56 +08:00
中午没休息把这一百多回复看完了,为啥同是做技术的你们都那么优秀
|
137
gouchaoer 2019-01-09 13:15:28 +08:00 via Android
还有抢活干的。。。如果要在服务端开 nodejs 的话我看干脆把 java 那些后端开除掉,直接 node 写后端就 ok 了,干嘛还要 node 跑去访问 java 后端 api 啊多麻烦
|
138
lychnis 2019-01-09 13:22:47 +08:00 via Android
黑猫白猫能抓老鼠就是好猫,抓的又快又好更不错
争论 xx 才是最强的 yy 这个问题是阻碍人类进步一大难题 |
139
phieo2018 2019-01-09 13:26:19 +08:00
我觉得服务端没错,你不要搞事情。
|
140
chinvo 2019-01-09 13:31:29 +08:00 via iPhone
说实话我是十分反感 ssr 的,毕竟要在服务器给跑个 node,对于中小项目多此一举。
如果你一定要用 react,可以考虑 react + 后端渲染,就是直接在后端模板里面写 react |
141
gaius 2019-01-09 13:42:17 +08:00
你只写静态页面难道不是很爽吗,jsp 又不是你弄
|
142
wangxiaoaer 2019-01-09 13:43:28 +08:00 4
@gz911122 #134 学东西是你自己的事情,别在生产上搞。例子中,jsp 技术栈出了问题有 后端负责,ssr 技术栈出了问题,楼主搞得定吗?
------------------------------------ 另外,忍不住再说几句,看到好多“ 2019 年了,还用 jsp ”这种言论,我想说恰恰都 2019 年了,希望你们懂得技术选型是满足业务需求、简化运维需求为第一要求的,不是酷炫吊炸天就是好,各种技术的产生必然是为了解决的某些问题,如果他解决的那些问题你本来碰不到,那有什么必要强上呢? 说到前后端分离,我认为选型有两点: 1 交互:都特么静态页面,交互很少,或者比较简单,哪怕你 100 多个页面,也请老老实实后端渲染。jsp 当模板用没你们想的那么不堪,以大多数应用的访问量、技术水平还轮不到需要更换 jsp 来解决性能的地步。典型如知乎,对,虽然他们目前用的前后分离,但是的确是在折腾,可能有反爬的考虑,但效果有限。 如果交互复杂,状态交织,类似百度地图、gmail、google docs 这种,但往往这种应用 SEO 的需求并不强烈,那就果断前端渲染,但是 jsp 渲染骨架,前端渲染内容,也不是不行。 2 变化频率:页面一天一个变,而且 jsp 是潜在 war 包里面的这种,每次更新要打包,这种情况明显前端渲染更有优势,前端打包成静态页面后更新快啊。 所以选什么,真特么跟年代关系不大,用 jsp 并不代表就用 jdk1.5,纯手工部署。 我们现在的方案: maven + spring boot + jsp + vue + jenkins + git, jsp 作为后端模板,静态页面直接输出全部内容,动态页面只负责输出骨架,剩下的由前端用 vue(webpack)开干,互不干扰。 |
143
hv3s1 2019-01-09 13:44:02 +08:00
前端娱乐圈...
|
144
wangxiaoaer 2019-01-09 13:45:32 +08:00 1
@wangxiaoaer #142 补充上面,现在这套方案基本可以做到”提交-发布-打包-部署-重启更新“整个过程的全自动。
|
145
q397064399 2019-01-09 13:45:47 +08:00
@wuliao49 #14 说汇编的就是抬杠,你跟他讲有什么意思,这种人我都是直接 block
|
146
livnimasileid 2019-01-09 13:48:56 +08:00 via Android
@alexsunxl 你潜意识是不是觉得如果他是你说的那么高工资就可以这样对你说话了
|
147
hellowes 2019-01-09 14:01:03 +08:00
JSP 能解决问题为什么不用?技术选型可能 react 更优秀,但是在公司干活要考虑整个团队能不能接受
什么?他们都接受不了?为什么一定要听你的?少数服从多数,不然就离开这个团队 |
148
mars0prince 2019-01-09 14:12:09 +08:00 5
@ytll21 我开始也是这么想的,后来发现,所谓的对公司负责,就是对自己的不负责。你挺负责的写 jsp,结果年底公司发现你没啥用,就把你裁了,你出去拿着这点经历发现根本没人要。这点道理也是前 leader 教育我的,我觉得挺对的,人不为己为谁呢,你就是个打工的而已。
|
149
serge001 2019-01-09 14:20:06 +08:00
@wangxiaoaer 知乎现在的交互跟业务逻辑 你确定用 jsp 能够搞定吗....
|
152
ytll21 2019-01-09 14:38:34 +08:00
@mars0prince 公司发你工资,然后你不想对公司负责任?抱歉我不理解你的思路。我在公司项目中用到的技术都是我确定掌握的技术,所有的新技术,我在用到实际项目前,都会自己用业余时间,把每个可能出现的问题点踩一遍。我觉得这才是对别人,对自己负责的态度。
|
153
KuroNekoFan 2019-01-09 14:41:19 +08:00
感觉 ssr 是比较麻烦,没具体实践过也不好多说
|
155
skyworker 2019-01-09 14:46:42 +08:00
|
156
gz911122 2019-01-09 14:49:04 +08:00
@wangxiaoaer 不上生成环境实践你永远不知道你是不是真的掌握了
|
157
tearslee 2019-01-09 14:51:30 +08:00
对不起,身为一个后端,没有掌握过高大上的 React,更没有用过 SSR.只能这样说,如果页面是你负责,数据也是你填,后端只给接口,那么前端你用什么技术随意, 但是如果接口对接是后端自己完成,那你还说乖乖的使用 html 给后端吧,又不是每个后端都会 React ,懂得怎么配合,但是基本每个前端,应该都会 html 吧?
|
159
racecoder00 2019-01-09 14:54:06 +08:00 1
默默地丰富 block 列表
|
160
KuroNekoFan 2019-01-09 14:54:16 +08:00
@lihongjie0209 还在用 jsp 的公司,怎么可能会有 ci/cd 呢
|
163
huguang3320 2019-01-09 15:31:09 +08:00
JSP 没什么,我们组没有前端开发,那怎么办?页面清一色都是 jsp,都是我们后端人员自己写的,当然我们项目不是前后端分离,所以比较 LOW,但是我总觉得技术不分新旧好坏,能完成需求就 OK。
|
164
zhouhui 2019-01-09 15:45:06 +08:00
你是否可以全部 hold SSR 出现的所有问题?
需要额外需要多少技术成本? 技术成本和收益是否成正比? 出了问题假如你不在。 有多少人可以 hold 住的? 建议把技术栈做简单点。 jsp 里边也有模版的概念。 用 https://www.thymeleaf.org/ 也不错。 |
165
lihongjie0209 2019-01-09 15:45:32 +08:00
@KuroNekoFan 你还真以为 ci/cd 有多高大上, jsp 有多 low ?
|
166
mars0prince 2019-01-09 15:46:29 +08:00
@ytll21 每个人想法不一样,道不同不相为谋,我只根据我工作这几年的经历给楼主一个参考,因为我也是从 jsp,jquery 一步一步踏过来的,感觉楼主经历和我很相似,不然也不会花时间写这么多了。仅供楼主参考,其他的我不谈了。
|
167
passerbytiny 2019-01-09 16:05:23 +08:00
@wangxiaoaer #141 Spring Boot 都用了,thymeleaf 或 freemarker 最多花一天熟悉一下就能用,你为什么还要用 JSP。
@lihongjie0209 #162 JSP 没什么 low 的,只不过流行的 Spring 不推荐使用它罢了 JSPs should be avoided if possible, there are several known limitations when using them with embedded servlet containers. —— https://docs.spring.io/spring-boot/docs/1.5.18.RELEASE/reference/htmlsingle/#boot-features-spring-mvc-template-engines |
168
wly19960911 2019-01-09 16:15:51 +08:00
我现在还改着老项目呢,无所谓了,爱写不写。都是 jsp 的。
|
169
Ritr 2019-01-09 16:29:53 +08:00
有个老人说的好,不管黑猫白猫,抓住老鼠就是好猫,终结
|
170
wangxiaoaer 2019-01-09 16:37:09 +08:00
@serge001 #149 看清楚,我说用 jsp 作为 模板引擎 是没问题的,mvc 的 view 层,业务逻辑跟模板是独立的,我上文说的交互逻辑复杂的情况下才需要考虑前端渲染,这个交互逻辑是指用户界面的交互,而不是业务的逻辑。
|
171
wangxiaoaer 2019-01-09 16:39:32 +08:00
@passerbytiny #167 因为 jsp 开箱即用,作为一个模板引擎,足够了,我们又不在 jsp 里面做过多逻辑,顶多一些条件判断之类,至于性能,没遇到瓶颈,自然没有换的动力。
|
172
ytll21 2019-01-09 16:45:28 +08:00
@mars0prince 通常一个项目的周期比较长,让我们换一个场景。比如你是一个厨师,你有很远大的志向,想要做一个米其林五星级厨师。有一天你有了一个很棒的 Idea,咸鱼头批萨。你迫不及待的想磨练你的新菜式,于是无论客户想要什么样的批萨,芝心的,新奥尔良的,你统统给他们做 - 咸鱼头批萨。不久,你的咸鱼头批萨终于让你一举成名,你成为了世界知名的厨师,但是,你的老东家,倒闭了。。。这真的是你想要的吗?
|
173
zyj20181225 2019-01-09 16:45:39 +08:00
我能说,我们现在做的是后台管理类项目,然后,一个人负责前后端的实现吗....2-3 个人在做,每人实现不同的模块,各自模块的前后端,自己写,基本就 3-4 个月完成一个项目.嗯,用的 jsp,UI 框架是 layui.
|
174
momowei 2019-01-09 16:50:46 +08:00
看到很多人鄙视 jsp,我也是笑了,我不可否认 java 模板确实某些时候是更好选择,但 jsp 无非就是不利于单元测试的官方模板技术,因为 jsp 依赖容器,而模板不依赖于 servlet 容器,从渲染角度来说,jsp 和 spring boot 推荐的模板又有什么区别咧,,还 jsp low.后端的 low 远远不是在 jsp 和模板的技术选型上。
|
175
fundebug 2019-01-09 16:51:02 +08:00 1
用 JSP 或者用 React 都行,听老大的就好了。如果你不认同老大,那就辞职。。。
|
176
fyxtc 2019-01-09 16:52:44 +08:00
吃瓜路过。。。。
|
177
yhxx 2019-01-09 16:56:45 +08:00
@ytll21 楼主遇到的例子显然是,厨师得到了一把锋利的刀,终于有机会要做一盘好菜了,旁边负责烧火的人逼他用 10 年前买来的生满锈的那一把旧的。
|
178
kylix 2019-01-09 16:57:01 +08:00
纯路过,感觉 V2EX 上前端好多,
不敢妄言了,瑟瑟发抖。。。 |
179
ytll21 2019-01-09 17:04:06 +08:00
@yhxx 哈哈,好的,顺着你的话说。1. 无论用的是锋利的还是生锈的刀,都是无法保证楼主做出的是盘好菜,所以,刀和好菜之间没有必然关系。2. 买刀是需要成本的,如果为了做好菜的前提是厨房的每个人都要换刀,老板不一定肯呀。。。
|
180
zyj20181225 2019-01-09 17:06:43 +08:00
我觉得,如果楼主听这个 5 楼的话的话,应该觉得是 java 也是被淘汰的技术了,直接前端一条龙搞定一整个应用的.建议你们老板把写 java 的都开了吧,按 5 楼的逻辑根本就用不到啊,非用 java 获取数据干嘛?
|
182
zyj20181225 2019-01-09 17:22:32 +08:00
对楼主的建议是,要么服从,要么离职吧.写 JSP 显然是对于你的前端发展没什么帮助的,如果让自己满意的下家的接手的话,离职吧.
|
183
passerbytiny 2019-01-09 17:23:06 +08:00
@wangxiaoaer #167 就算不考虑 JSP 的 Servlet 本质,它表面上也是对比 PHP、ASP 的 HTML 脚本语言,语法上即不是 Java,也不是 HTML。Thymeleaf 是完完全全的 HTML,Freemarker 是 HTML 加标记,要论开箱即用,怎么着也轮不到 JSP。如果不是因为文档上懒得把章节名描述为模板引擎或者 JSP,它不会被放到模板引擎章节中,因为它不是。
@momowei #170 你确定你懂 JSP 了? |
184
66beta 2019-01-09 17:24:18 +08:00 via Android
跟老板说,Java 全部改微服务,前端做接口层,兼容多端
然后开掉几个 Java,再招几个前端,你当 leader,迎娶白富美 |
185
yhxx 2019-01-09 17:40:56 +08:00
@ytll21 那我就继续来杠一会
无论用的是锋利的还是生锈的刀,都是无法保证楼主做出的是盘好菜,但是用锋利的刀,能做出好菜的概率显然更大。 有的时候有的菜还真的是必须用好刀才行,如果这种时候老板都不肯买刀,那该考虑换个老板了。 |
186
cccssss 2019-01-09 17:42:09 +08:00
前端不都是外链 js 么,为什么要拉整个 java 项目调试?都上 React 都上 SSR 了,还搞不定动静分离?
如果是 HTML 结构的话,浏览器 f12 不是更方便么? 如果连动静分离都搞不定,那我估计 React 服务器部署、发布也搞不定吧。那你帮后端调调 bug 解决下问题有啥不应该的么,毕竟如果你搞不定服务器那一套,后端人家不还得学习怎么帮你部署和调试? 另外:PHP 是世界上最好的语言,不接受反驳。9021 年了还用 java 这种落伍的语言,不是我说,在座的都是辣鸡 |
188
vacanda 2019-01-09 17:45:18 +08:00
不用就不用。
|
189
WilliamYang 2019-01-09 17:48:15 +08:00
哈哈, 还在用 jsp
|
191
signalas1 2019-01-09 18:06:31 +08:00
@zyj20181225 后台有一些富杂前端的表格编辑场景筛选,一堆交互下来,jQuery 特别浪费生命
|
192
signalas1 2019-01-09 18:07:46 +08:00
小业务 搭个 node 也不会出大问题,出问题了和 JVM 解决方法差不多,大不了重启,弄个服务器渲染成本很低。
|
193
signalas1 2019-01-09 18:10:52 +08:00
@huguang3320 你问问自己的内心,加需求的时候前端页面写起来是不是很酸爽,一片一片的粘,对着位置找
|
194
rickzh 2019-01-09 18:13:27 +08:00
路过 v2 前端好多啊 瑟瑟发抖
|
195
zhangkunkyle 2019-01-09 18:13:47 +08:00
@66beta 哈哈哈,妙计
|
196
signalas1 2019-01-09 18:14:19 +08:00
@cccssss 注意审题朋友 楼主准备 java node react, 工友准备让楼主切图写好 HTML,工友来 HTML-> jsp
|
197
cccssss 2019-01-09 18:24:09 +08:00
@signalas1 我没审题错误啊
如果前端就楼主一个人,我是项目负责人,我也会选择 jsp 或者 xxp 或者 xxmaker 之类的方案。 关键节点和瓶颈压在 1 个人身上,项目风险太高。 我说的是楼主补充里说调 bug 还需要拉 java 项目 动静分离,js css 外链域名,自己本地起一个 nginx,host 指向本机,前端的什么 bug 是搞不定的? 如果还需要拉整个 java 项目才能调整前端 bug 的前端、架构水平,不允许去搞 react 和 ssr 从我看来,是这个项目负责人做的可能是这个项目里最正确的一件事,没有之一。 |
198
cccssss 2019-01-09 18:27:56 +08:00
@signalas1 我说的 PHP 是世界上最好的语言,完全是针对这帮说 jsp 就是落后的,不应该使用的技术的人说的。不同业务场景,不同技术栈,不同技术积累。
一锤子就给敲死了,那我就可以直接说,这帮小辣鸡还讨论 java 这种古老落伍的语言,不去使用 php 这个世界上最好的语言,统统都是辣鸡,而且也是没有之一那种辣鸡。 |
200
wangxiaoaer 2019-01-09 19:09:18 +08:00
@passerbytiny #183 哈哈,我说的开箱即用是说在 java 的环境下,无论是 tomcat 下部署还是内嵌,都支持 jsp,不需要额外的 library 引入,至于语法,我们用的基本就是 html + jstl 标记,因为很少有业务逻辑,所以用起来没发现什么不适应的地方,也就没有升级换代的想法了。
|