@samuel37 你从哪里得出是捡漏的？我购买需求是刚需，只是没有全新的需求，觉得二手的够凑合使用价格合适就可以了。但是某些二手电子产品卖家真的是宰一个赚一个，二手贵过全新我是真服

@anguiao 你说得很有道理，我是真的被咸鱼惊呆了，尤其是显卡内存，各种标价比肩全新产品

相对于其他二手货，在电子产品上，好像并不存在“处物”情节

@NetworkManager 1050ti 和显示器的搜索出来的结果基本上都是在这个范围上下 50 元，现在才知道电子产品是真的保值。

@zidian 你认真看了吗，我是说家具这个价格很便宜，电子产品不可能期望这个价格

@mystrylw 没人逼着你吃饭呀= =
原本计划显示器、内存和显卡都从咸鱼捡垃圾的，最后都买了新的

很明显你所有选择里并不包含修改你自己的观点，你是对的，我们无法交流

打呼噜是扁桃体，睡觉的时候把嘴巴贴起来，闭合了就完了，但是你这鼻子声音，实在是没办法呀

@CeresLC
是中科院还是工程院？

你又不玩游戏，干嘛硬是要用 Windows

996 真的不够，我记得高考那年，每天除了学校安排的作业，自己每天额外做一张理综一张数学一张英语一张语文，四张试卷（作文不写）。班上最努力，最后考得最好的老哥，每天只睡三四个小时，中午趴桌子上睡十分钟。
我个人还是比较感谢高考制度的，也很后悔当初不够努力（高一高二都在看小说中度过）。但是内地老师水平低下是真的，基本上老师的学校在班上所有同学的后来考上的学校中，都是中下档次的。教东西讲得层次不深，听课还不如自学效率高。
没本事没条件改变世界的，就努力改变自己，打不过就加入吧。家里有矿的，当我没说吧。

写文档写教程做 ppt 和教别人最难，用最通俗的语言让别人理解你的产品和技术，真的是难

@murmur
首先，我认为企业开发的复杂还有很多地方有体现。
1、比如你要做一个采购的功能，手机和铅笔有不同的属性，铅笔要有长度，笔芯粗细，品牌这些字段，手机要有 rom，ram，显示器，摄像头这些参数，信息录入界面不一样，但是代码层面还是要走统一处理，不能说来一个品类就开发一次吧？这是最简单的例子，在单据，票据等等方面都有大量类似的业务，这些是非常复杂的。
2、至于你说的工作流，流程是非常成熟和独立的，但是也就是相对简单的业务而言，对于大客户的领导，永远有你想不到看不懂的操作，比如“小 X，这个审批不能通过的，你们这个按钮太不合理了，我一下就点到通过上了，给我改回来，那个流程上也别让人看到我之前给他通过了”
3、性能，这个渲染过程实现方法不同，所以我们讨论的不一样，你们采用的方案是生成统一缓存模板，读取模板其实就是读取 html，和传统的 jsp 页面性能没什么区别。但是如果用即时渲染方案，在前端或者后台根据数据去走，即时生成页面或者 dom 的话，性能影响还是很大的，这种方案好处体现在对我说的第一点支持度很好，在页面权限与数据权限的汇入时，也更好操作。
4、并发量也是取决于不同企业的不同产品需求的，不能一概而论，但是如果真的哪天有高并发需求，那真的要哭了。我们遇到一个比较特殊的对硬件的需求，就会在特定事件发生时，所有硬件同时运转，并发量瞬间爆棚。

我认为，这种开发框架有好有坏，作为开发辅助框架是很好的，能够很大层次上提升增删改查的效率，但是真的不要作为主框架使用。它的定位应该是效率提升工具，而不是用它的能力去定义业务开发的上限。

我待过的两个团队就是专门开发这种类似的拖拽式框架，都是提供给公司内开发人员作为基础框架使用，我本人做了两三年的相关工作，应该有发言权吧？
首先，毫无意外的，这两个拖拽式框架最终都是走向边缘化，好一点会被作为辅助开发工具，因为我们会帮助他们生成基本的一套增删改查代码，生成较为简单的页面逻辑。
至于楼上那些说的内部实现机制，简单的说就是数据收集与分析渲染，设定好一套规则和接口，按照我们的数据逻辑去走执行器。
存在什么问题会被废弃呢？
1、在过于灵活的业务的环境中表现不佳，本来应该是开发去实现业务功能，结果业务要向框架妥协，按照框架的标准和实现方式去做。
2、性能，前端数据渲染与后台大量反射的使用都会导致性能问题。
3、debug，这种模式下，不熟悉整套机制，你想 debug，难于登天。
4、技术迭代，要有个新需求，技术迭代你得等非常久。
5、开发人员的反对，这种类似的框架目的就是降低业务开发人员的开发难度，降低开发成本，但这是公司层面的优势，对于开发者是价值的降低。

劝你早点退坑，你现在还能绑定事件，后面你会发现，js 都是你画流程图配出来的了

棋子的信息数据是手动录入的吗？有些棋子在正式版本中已经被移除了，但是还可以在阵容模拟中看到哦

@20015jjw 新组一台

@axbx 带哥，SN500 ￥ 385 是哪里的，求上车