投用友秋招，笔试刷掉的人比面试多得多。尤其是2017年那批题，表面看是常规的Java、SQL、计算机基础，实际上每道题都藏着用友的业务底色——ERP、财务报表、供应链流程。我当年就是吃了没准备业务题的亏，选择题靠基本功扛过去了，一到业务场景题直接懵。这篇文章把当时那套笔试题里最有代表性的题重新梳理一遍，题目是回忆整理版，但考点和思路完全按当年实际考察的方向来，给准备投用友的同学做个参考。
1. 用友秋招笔试的基本盘：题型分布与备考方向
1.1 当年笔试到底考了什么
用友2017秋招的技术岗笔试试卷，整体结构可以分为四块：计算机基础知识、Java（或C++）语言基础、数据库SQL、业务场景题。前两部分占了大约50分，数据库大约20分，业务场景题30分。这个分布和很多互联网公司不太一样——互联网公司喜欢堆算法题，用友更看重你对企业级应用开发的综合理解。
为什么这么设计？用友的核心产品线是U8、NC、U9这类ERP系统，客户是制造业、流通业、服务业的大中型企业。这些系统的特点是什么？数据量大、业务流程复杂、权限管控严格。一个只会写算法题的应届生，进来连采购订单和销售出库单的关联都搞不清楚，更别提动代码。所以笔试必须筛选出那些既懂技术、又愿意理解业务的人。
那套题还有一个务实的地方：不考偏题怪题。我印象很深的是选择题里几乎没有冷门语法，全是日常开发中用得到的东西。这意味着只要你认真复习过Java基础和SQL，这部分拿分是不难的。真正的分水岭在业务场景题，那才是用友挑人的核心标准。
1.2 不同岗位的题目差异
用友秋招不是只有一个岗位。我当时投的是Java开发，后来和几个一起面试的朋友交流过，发现不同岗位的笔试题差别挺大的：
- Java开发岗：Java基础占比最高，业务场景题偏向财务和供应链领域。
- C++开发岗：C++语法和内存管理是重点，业务题相对简单一些。
- 前端开发岗：会考HTML/CSS/JavaScript，业务题比例低，更看重交互设计和代码规范。
- 测试开发岗：数据库SQL题分值明显提高，还会考测试用例设计的基础知识。
- 实施顾问岗：不考编程题，但业务场景题难度加大，还加了财务基础知识的简答题。
所以准备笔试前，先看清楚自己投的岗位。我见过很多人明明投了开发岗，却在拼命准备财务知识，最后基础题没做好，业务题也没答到点上，两头空。
1.3 笔试的淘汰逻辑
用友笔试的淘汰率很高，尤其是开发岗。让我印象最深的一点是，它不看你单题得分，而是看总分排名。也就是说，如果你业务题答得一般，但基础题几乎全对，依然有机会进面试。反过来，基础题错误太多，就算业务题写得天花乱坠，也可能被刷下来。
为什么这么设计？因为用友觉得基础不牢的人，业务理解再深也写不出靠谱的代码。ERP系统最怕什么？最怕程序员的低级错误导致数据错乱。一个事务没处理好，可能让一整天的财务数据对不上账，这种事故在客户现场是致命的。所以基础扎实是底线，业务能力是加分项。备考的时候，基础题的正确率应该优先保证，业务题是拉分的手段。
2. 基础知识选择题：别小看这些“送分题”
2.1 数据结构与算法的基础考察
用友笔试题里的数据结构部分，难度比互联网大厂低不少，但它考得很有针对性。我当时遇到的一道题是这样的：
给定一个单向链表，只给出头指针，如何判断链表中是否存在环？时间复杂度要求O(n)，空间复杂度要求O(1)。
这道题看着简单，背后考的是快慢指针的思想。如果只答“用快慢指针”，只能得一半分，因为阅卷老师要看到你对边界情况的考虑——链表为空、只有一个节点、环在链表中间而不是尾部，这些情况都必须覆盖到。我当时直接写了思路，用了三个if分支处理边界，后面笔试过了才知道这题是踩点给分的。
另一类高频题是排序算法的稳定性。我遇到的题目是问“下列哪种排序算法是稳定的：A. 快速排序 B. 堆排序 C. 归并排序 D. 选择排序”。答案是归并排序。这道题本身不难，但用友在题目后面加了一问：“在ERP系统的数据列表中，为什么排序稳定性很重要？”很多人在这道题上栽了跟头。因为ERP系统里经常出现多字段排序，比如先按客户分组，再按订单日期排序，如果排序算法不稳定，相同客户的分组顺序会乱掉，报表显示就不好看。
2.2 Java基础：字符串、集合与异常处理
Java基础部分是重头戏。用友的Java题不考那些面试八股文里的偏题，反而特别偏爱字符串操作和集合类的底层原理。有一道题我印象很深：
String a = "hello"; String b = new String("hello"); 问 a == b 的结果是什么？a.equals(b) 的结果是什么？
答案是第一种是false，第二种是true。这道题考的是字符串常量池和对象引用的概念。第一行代码在常量池里创建了一个对象，第二行代码在堆内存里创建了一个新的字符串对象，所以==比较的是内存地址，不相等。我当时差点答错，因为很多初学者只知道String是不可变的，却不知道常量池和堆的区别。
集合类的题目更典型。有一道是问HashMap在什么时候会进行扩容，答“当元素数量超过负载因子乘以当前容量时”。这是标准答案，但用友还追问了一句“如果多个线程同时操作同一个HashMap，会有什么风险？”这就是在考察你对并发问题的理解和处理能力了。HashMap在JDK 1.7及以前的版本中存在并发死循环的隐患，多线程同时put时可能导致链表形成环，CPU飙到100%。虽然在1.8以后引入了红黑树，但并发场景下依然可能丢失数据，所以还是应该用ConcurrentHashMap。
异常处理题也很实际。题目给了一段代码，try块里有一个除零操作，catch块里打印异常信息，finally块里关闭一个流，问输出顺序。这道题考的是try-catch-finally的执行顺序和异常处理的基本逻辑。用友考这个是因为ERP系统里的代码大部分都涉及文件操作、数据库连接等资源释放问题，如果开发者不重视finally块的写法，很容易导致资源泄漏，生产环境跑久了就会内存溢出。
2.3 数据库基础：索引与事务的初步考察
数据库部分的第一类题是索引。我当时遇到一道选择题：“在数据库表中，为经常作为查询条件的字段建立索引，通常能显著提升查询效率，这是因为什么？”选项里有“减少了数据扫描的行数”、“将数据变成了有序结构”、“缓存了查询结果”等。正确答案是减少了扫描行数。这道题很多人靠背概念也能选对，但用友后面跟了一道实操题：“如果一个表经常执行UPDATE操作，对这个表的字段建立索引会有什么影响？”
这题就得动脑子了。索引能加速查询，但每次UPDATE操作都需要同步维护索引，索引建多了，更新语句的性能就下降了。在ERP系统里，很多表是高频更新的，比如库存表，每笔出入库都要实时更新。如果开发者在这些表的每个字段上都建索引，查询是快了，但业务高峰期的更新操作会变得很慢，客户那边就会抱怨系统卡顿。所以索引不是越多越好，要在查询和更新之间找平衡。
事务部分考得更实际。用友笔试里有一道关于事务隔离级别的问题，场景是：财务人员在录入一笔凭证时，另一个操作员正在查询当月汇总金额，要求查询过程中不能看到未提交的凭证数据。这题的选项包括读未提交、读已提交、可重复读、串行化。正确答案是读已提交或更高的隔离级别，因为读未提交会让查询操作看到还没提交的脏数据，汇总金额就会出错。
3. 数据库SQL题：业务场景下的真实查询
3.1 多表关联查询：销售订单与客户信息
用友笔试的SQL题不是让你写一个简单的SELECT，而是给一个完整的业务背景，然后让你写查询语句。我记得当时有一道题是这样的：
有两张表——客户表customer（字段：id, name, city, level）和订单表orders（字段：id, customer_id, order_date, amount）。请查询2023年度下单总金额排名前10的客户，输出客户名称、所在城市、订单总金额，按总金额从高到低排序。
这道题考察的是多表关联、聚合函数、分组排序，以及如何取前N条记录。正确写法是这样的：
SELECT c.name, c.city, SUM(o.amount) AS total_amount FROM customer c INNER JOIN orders o ON c.id = o.customer_id WHERE o.order_date BETWEEN '2023-01-01' AND '2023-12-31' GROUP BY c.id, c.name, c.city ORDER BY total_amount DESC LIMIT 10;有几个注意点值得说。第一，GROUP BY的字段必须包含SELECT中出现的所有非聚合字段，MySQL 5.7的默认配置下如果漏了会直接报错。第二，LIMIT的数值在不同数据库里语法不同，SQL Server用TOP，Oracle用ROWNUM，我当时用的MySQL所以写LIMIT。第三，如果客户存在多个订单金额相同的边界情况，这个查询用LIMIT取前10可能会有疏漏，但笔试里一般不考虑这种极端情况，重点是写出正确的关联逻辑。
3.2 子查询与统计：库存表的实时汇总
另一道SQL题更有用友特色。题目背景是库存管理，表结构是这样的：库存明细表stock_detail（字段：id, product_id, warehouse_id, change_qty, change_type, change_date），其中change_type为1表示入库，为2表示出库，change_qty是变化的数量。要求查询各仓库的当前库存量。
当时我看到这道题的第一反应是直接按warehouse_id分组，然后用SUM(CASE WHEN...)分别统计入库和出库。但题目里还有一个隐含要求——要查出那些当前库存为负值的仓库，因为在实际业务中库存为负说明数据有问题，需要排查。
SELECT warehouse_id, SUM(CASE WHEN change_type = 1 THEN change_qty ELSE 0 END) - SUM(CASE WHEN change_type = 2 THEN change_qty ELSE 0 END) AS current_stock FROM stock_detail GROUP BY warehouse_id HAVING current_stock < 0;这题的价值在于它考了HAVING过滤聚合结果的能力，而不是WHERE过滤行记录。很多人写SQL时，习惯把所有条件都塞进WHERE，但WHERE的执行时机在分组之前，聚合函数的结果必须用HAVING来过滤。这个区别在笔试里写得出来，在实际开发里也特别实用。
3.3 索引失效的经典场景：函数操作
还有一道题是问下面这个查询为什么会慢：
SELECT * FROM employee WHERE YEAR(hire_date) = 2020;原因是hire_date字段上套了YEAR()函数，导致索引失效，数据库必须做全表扫描。正确写法是：
SELECT * FROM employee WHERE hire_date >= '2020-01-01' AND hire_date < '2021-01-01';这道题在笔试卷子里出现得很有技巧，因为它考察的不是你是否知道YEAR函数，而是你是否理解索引生效的条件。我在做这道题时犹豫了很久，因为选项里还放了一个“查询结果集过小，优化器自动改为全表扫描”的干扰项。实际上，优化器只有在数据分布极端不均衡时才可能放弃索引，你这个例子里数据量又不算小，所以不能选。
4. 业务场景题：用友笔试的真正分水岭
4.1 财务模块：理解借贷记账法
用友是做ERP出身的企业，最核心的模块就是财务核算。所以业务场景题里，财务题是必考的。我当年遇到一道题，给了一张简单的凭证表：
一张会计凭证包含：凭证号、日期、摘要、会计科目、借方金额、贷方金额。现在要求查询所有借贷不平的凭证，即借方总额不等于贷方总额的凭证。
这道题本质上是考GROUP BY和HAVING的组合使用，但它的业务背景让难度提升了——如果你连借贷记账法的基础都不懂，可能压根看不懂题目在问什么。
SELECT voucher_id, SUM(debit_amount) AS total_debit, SUM(credit_amount) AS total_credit FROM voucher_detail GROUP BY voucher_id HAVING SUM(debit_amount) != SUM(credit_amount);这道题背后其实还考察了你对用友产品数据的理解。在NC或U8的凭证表里，一张凭证的借方金额和贷方金额必须相等，这是财务记账的基本规则。如果开发人员不理解这个规则，写出的查询逻辑可能就是错的。我当时把借方和贷方算反了，后来复盘发现是对业务理解不够，而不仅仅是SQL语法问题。
4.2 供应链模块：采购入库与暂估业务
供应链相关题是用友业务题的另一个重点。有一道题是考察采购入库和暂估业务逻辑的。题目背景是：企业采购一批原材料，货已入库但发票未到，月末财务需要做“暂估入库”处理。下月初红字冲回暂估，收到发票后按实际金额入账。
这道题要求根据上述流程，设计一张数据库表的字段，并说明各字段的作用。我当时设计的字段是：id、入库单号、物料编号、数量、暂估单价、实际单价、供应商编号、入库日期、冲销状态、备注。现在回头看，这个设计基本合格，但漏了一个关键字段——业务类型，用来区分“暂估入库”和“红字冲回”。没有这个字段，后续做数据分析时根本没法区分业务类型，报表就乱了。
这类题目考的不是你能不能写代码，而是你能不能站在一个ERP实施顾问的角度，理解企业实际业务中的复杂场景。用友的产品之所以复杂，就是因为它在处理这些真实业务规则时要做大量的分支逻辑和状态判断。应届生如果在这类题上能答出一些自己的理解，面试官会明显高看你一眼。
4.3 权限管理：ERP系统里的数据隔离
还有一道题让我印象很深，是关于权限设计的。题目是：
在一个集团型企业的ERP系统中，不同公司的财务人员只能查看自己公司的数据。请设计一个简单的权限控制方案，并说明如何防止越权访问。
这道题看起来是个开放性问题，但用友是有一套标准的回答思路的。最直接的方案是“数据权限隔离”，也就是在业务表里加一个company_id字段，查询时强制带上公司条件。但这只是最基础的做法，因为集团财务总监可能需要看所有公司的汇总数据，所以权限控制不能是简单的一刀切。
我当时在答题时给出了一个分层方案：用户表、角色表、角色权限表、公司权限表，通过用户-角色-公司三层关联来控制数据范围。而且，前端不能作为权限控制的唯一手段，后端接口必须再次校验用户是否有权访问该公司数据。这道题答完后，我自己都觉得思路清晰了很多，因为它强迫你把一个真实业务场景的权限模型理清楚。
5. 编程题：手写代码背后的工程思维
5.1 字符串处理：订单号生成的规则
用友的编程题不走竞赛路线，而是给你一个真实的业务场景，让你手写代码解决。我遇到的第一道编程题是：
某ERP系统需要生成一个20位的订单号，规则是：前4位是年份，第5到第8位是月份和日期，后面8位是当天订单的流水号（从00000001开始），最后4位是仓库编号。请用Java实现一个方法，输入年份、月份、日期、仓库编号和当天第几单，输出完整的订单号。
这道题本身不难，就是字符串拼接和填充格式。我当时的写法是：
public String generateOrderNo(int year, int month, int day, int warehouseCode, int orderSeq) { String yearPart = String.format("%04d", year); String datePart = String.format("%02d%02d", month, day); String seqPart = String.format("%08d", orderSeq); String warehousePart = String.format("%04d", warehouseCode); return yearPart + datePart + seqPart + warehousePart; }但真正踩分的地方在于，题目后面还有一句追问：“如果当天订单量超过99999999，你如何处理？”很多人觉得不可能，但在大促或月底冲量场景下，还真有可能接近这个上限。更合理的做法是流水号到达上限时报警提示，或者按业务规则重新编号。面试官看到你能主动考虑这个边界问题，比你把主流程写完更加分。
5.2 数据结构：用Java实现一个栈
还有一道编程题是让用Java实现一个字符串反转栈，要求支持push、pop和查看栈顶元素三个操作。这道题看着太基础了，但用友在这道题上设置的陷阱是“请用数组实现，不要用Java内置的Stack类”。原因在于，内置Stack类是基于Vector实现的，线程安全但性能较差，在企业级应用的高并发场景下并不推荐。笔试题的意图是考察你是否真的理解栈这种数据结构的内部实现，而不是只会调用API。
public class StringStack { private String[] data; private int size; private int capacity; public StringStack(int capacity) { this.capacity = capacity; this.data = new String[capacity]; this.size = 0; } public void push(String item) { if (size >= capacity) { throw new RuntimeException("Stack is full"); } data[size++] = item; } public String pop() { if (isEmpty()) { return null; } String item = data[--size]; data[size] = null; return item; } public String peek() { if (isEmpty()) { return null; } return data[size - 1]; } public boolean isEmpty() { return size == 0; } }这道题想拿满分，有三个细节必须做对。第一，pop时要把数组里的引用置空（data[size] = null），否则会有内存泄漏隐患。第二，要检查栈满和栈空的边界情况。第三，要在类头部写清楚泛型声明，虽然题目没要求，但写了能体现你的代码规范意识。我当时就因为这几点多拿了一些印象分。
5.3 逻辑题：经典的分油问题
除了代码题，用友笔试还喜欢出一些逻辑题，考察你的思维灵活性。有一道题是这样的：
有一个8升的桶装满了水，还有两个空桶，一个5升，一个3升。要求不使用其他工具，精确量出4升水。
这个题和以前那个“用3升和5升桶量出4升水”的经典题是同一个解法。步骤是：先把5升桶装满，倒入3升桶，5升桶剩2升；把3升桶倒空，把5升桶里的2升倒入3升桶；再把5升桶装满，倒1升到3升桶使其满，5升桶就剩4升了。
这道题考的不是数学能力，而是你有没有耐心在有限时间内分析问题。很多人一看到这种题就慌，但用友并不是要你立刻答出来，而是看你如何组织思路。我当时在草稿纸上画了个桶的示意图，一步步推演，最后给出了完整步骤。面试官后来告诉我，这道题很多人直接放弃，能静下心来画图推导的反而显得很稳重。
6. 实操总结：备考用友笔试的关键思路
6.1 两个非技术层面的重要提醒
第一，注意笔试的时间分配。用友笔试题量大，尤其是选择题，大量阅读题面很耗时。我当时的策略是：先快速做一遍有把握的选择题，在题目上标记不确定的；然后直接做SQL题和编程题，因为这类题分值高；最后再回头看那些不确定的选择题，利用剩余时间仔细推导。千万不要在选择题上纠结太久，导致后面的大题没时间写。
第二，注意笔试环境的细节。如果是线上笔试，提前调试好摄像头和浏览器，关闭所有可能弹窗的软件。如果是在线IDE，写完代码后要自己多测几个边界用例，确认没有低级错误再提交。如果是线下笔试，注意字迹工整，SQL语句和代码用缩进整理好，方便阅卷人看。我见过有人在答题纸上把SQL写得挤成一团，阅卷老师根本懒得细看，直接按错误处理了。
6.2 备考建议：用友笔试考的是“企业级开发思维”
刷了这么多题，我最想分享的一点体会是：用友笔试真正想筛选的，不是刷题机器，而是具备“企业级开发思维”的候选人。什么是企业级开发思维？简单说就是：在写代码之前，先理解业务逻辑；在选技术方案时，考虑系统的稳定性、数据的一致性和权限的安全性；在遇到问题时，能主动考虑边界情况和异常场景。
如果你后续也想投用友或其他ERP厂商，建议在刷题时多做两步。第一步，花几天时间了解ERP的核心模块，包括财务、供应链、生产制造、人力资源，至少知道每个模块的核心业务表长什么样。第二步，把SQL的聚合查询、多表关联、子查询练熟，因为ERP系统里90%的功能都离不开数据库的高效查询。这两步做到了，再用友这类笔试题就从容多了。
