低代码是“未来”还是“骗局”？作为前端我被内耗到了
「我一个前端，最后成了平台数据填表员，写页面？不存在的。」
😅项目开始前，我是兴奋的
当领导说“这个项目我们用低代码平台做，提效百分百”，我甚至有点激动。
作为一个写了 5 年组件的前端老油子，谁不想脱离日复一日的 v-model 和 props 地狱？
领导还补充：“平台我们组自己封装的，配个 schema 就能跑，前端工程师只需要写逻辑。”
我一听这话，心想：
终于要进入“写配置赚钱”的时代了！
然而，我万万没想到——这段低代码旅程，最后让我怀疑人生。
😵上线第一天，我差点把键盘砸了
第一个需求很简单：
做个带搜索、分页、导出 Excel 的用户列表页。
我打开平台，选择“表格组件”，拖入“搜索框”，配置字段、绑定接口——一切都看起来毫无门槛。
结果运行之后，搜索没反应、分页错乱、导出根本没绑定。
我一查 schema，300 多行配置里，居然混了三种不同的写法：
{
"onSearch": "handleSearch",
"onSearch()": "handleSearch",
"onSearchEvent": "handleSearch"
}
问后端：“你这个文档是哪个是对的？”
后端说：“都对，我们兼容了。”
我瞬间明白：这不是低代码，这是自制混沌生成器。
🤯技术债太多，修个 key，整页全崩
最魔幻的一次，是我想修改表格的一个字段名，从 user_name 改成 username。
我只是改了 schema 的字段名，结果：
- 表格没显示
- 搜索没了
- 编辑表单也报错
- 提交接口直接抛了个 500
我调试了三个小时，才发现平台内部是按字段名 字符串拼接 key 绑定状态 的……只要字段名变了，所有逻辑都得重配。
我恍然大悟：
传统开发用 IDE 报错提醒你；低代码等你点击线上按钮才告诉你挂了。
😓协作地狱：产品配页面，我修 schema
最痛苦的不是技术问题，而是人。
产品说：“我来拖页面，你只用帮我看看为什么点了没反应。”
然后我收到一个 schema 文件，2000 行，不带注释，结构是这样：
{
"component": "Form",
"props": {
"items": [
{
"label": "名称",
"field": "formA.formB.userName",
"rules": "{ required: true }",
"props": {
"onClick": "fn1()"
}
}
]
}
}
我想问三件事：
- 你这个路径到底是怎么拼出来的？
- 为什么校验规则是字符串？
- 你拖了个按钮怎么会触发五个请求？
我调试一天，结论是：产品误操作删除了一个容器组件，但平台没报错，直接让数据结构断链。
🧨所谓低代码：把逻辑封死、把锅甩你
我总结这个项目两个最深的坑：
1. 复杂交互，低代码写不来
比如“用户选择类型后，自动拉接口重新加载选项”这种需求，纯配置根本搞不定。
最后我只能写自定义组件注入到平台里，甚至还要写类似：
platform.on("fieldChange", (field, value) => {
if (field === "type") {
reloadOptions(value)
}
})
这叫低代码吗？我写的代码比原来还绕。
2. 前端不是没活了，是变成了“修配置+查日志工程师”
- 页面功能跑飞了？前端看 schema；
- 按钮不响应？前端查绑定字段；
- 接口返回异常？前端加拦截 hook；
- 表单校验失败？前端写正则规则；
最后我只写了两行 JS，却维护了十几套 JSON。
我真的开始怀疑，前端的价值，是不是变成了“修别人的 schema”？
🧩我从这个项目学到的东西
不是说低代码没用，而是：
不是所有团队都配拥有一套低代码平台。
低代码系统真正的“提效”，需要这些前提：
- 强约束的规范体系（字段、组件、交互都必须有标准）
- 良好的权限隔离机制（避免“产品能改逻辑，运营能删字段”）
- 持续有人维护平台底层能力（不然技术债只会越来越重）
- 合理的分工协作机制（schema 的维护不应该是前端一个人干）
否则，它只是一个混乱责任分配工具，表面上 everyone can build，实际上 everyone push bugs。
📌低代码，不是骗局，也不是未来——是一个选项
如果你问我现在怎么看低代码？
我的回答是：
低代码不是“未来”也不是“骗局”，而是“项目管理方式的折中”。
它适合一些场景：
- 表单多、CRUD 重复度高的后台系统；
- 业务快速试错、页面变动频繁的 MVP 阶段；
- 运营自己想搭点落地页的场景。
但如果你希望：
- 页面复杂，交互灵活；
- 可测试、可维护、可拓展；
- 高性能、大工程；
那——你得写代码。
🗣最后
你也踩过低代码的坑吗？
有没有类似“debug 三小时发现产品配错 schema”的经历？
📌 你可以继续看我的《为什么》系列文章
来源：juejin.cn/post/7514611888991387667
前端难还是后端难？作为八年后端开发，我想说点实话
前端难还是后端难？作为八年后端开发，我想说点实话
前端容易吗？不容易。
后端轻松吗？也不轻松。
那到底哪个更难？
这事还真不是一句话能说清楚的……
一、先说说我个人的背景
我是一个写了 8 年 Java 后端的程序员，经历过中后台系统、金融系统、ToC App 的服务端架构，也跟前端打了无数交道。从最早的 jQuery 到现在的 Vue、React、Vite，从最早的 JSP 页面到现在的前后端分离，我见证了不少“变化”。
我不是要拉踩谁，只是想以一个偏后端开发者的视角，聊聊我对“前端难还是后端难”这个话题的理解。
二、前端的“难”是不断变化的“浪潮”
不得不承认，前端的变化速度是真的快。去年刚学完 Vue 2，今年要学 Vue 3；React 的 Hook 还没深入掌握，新的 Server Component 又来了；Webpack 配熟了，Vite 火了；CSS 还没写顺手，Tailwind 席卷而来。
除了框架和工具链的变化，更别说适配各种浏览器、屏幕尺寸、终端设备、无障碍要求、多语言、性能优化、SEO、交互设计……
而且最近几年，前端逐渐“全栈化”：你可能要写服务端渲染（SSR）、搞 Node 服务、上 Docker 部署、调数据库、甚至自己写接口 mock。
前端难吗？难，而且是越来越难。
三、后端的“难”是看不见的深度
后端的难，往往藏在系统的底层逻辑中。你可能看不到一个后端接口的“UI 效果”，但它背后往往涉及：
- 数据库设计 & 索引优化
- 分布式事务
- 消息队列 & 异步处理
- 缓存策略 & 数据一致性
- 服务容灾 & 高可用架构
- 权限系统、加密解密、审计日志
- 安全防护（SQL 注入、XSS、CSRF）
- 性能调优 & JVM 调试
- CI/CD、灰度发布、日志平台接入
而且一旦出问题，前端崩了是“用户体验不好”，后端崩了是“公司赔钱” 。这不是开玩笑，有一次我们一个订单服务接口挂了 5 分钟，损失了几十万。
后端难吗？当然难，而且是“看不见但不能错”的难。
四、我最怕的不是“前端难”或“后端难”，而是互相看不起
说实话，我见过太多前后端互相“看不上”的情况：
- 后端觉得前端就是摆样子，“你不就封个壳子嘛？”
- 前端觉得后端接口又臭又长，“你这 JSON 谁看得懂？”
- 后端吐槽前端不会调接口，前端吐槽后端不会写文档……
但你仔细去看，一个优秀的前端开发，往往比很多“伪全栈”更懂系统结构；一个优秀的后端，也会在意接口的易用性、响应速度和文档清晰度。
技术没有高低，但人有格局。
五、站在“代码人生”的角度看，难易是阶段性的
我年轻的时候觉得后端“更高级”，因为能接触系统底层、数据和业务逻辑。但这几年，我越来越觉得前端也有它独特的价值：
- 是前端让用户第一眼喜欢上产品；
- 是前端让复杂的系统变得“看得见”；
- 是前端在用户和系统之间，搭了一座桥。
你说哪个更重要？没有谁离开谁就能独立运行的系统。
我现在更看重的是协作、共建、以及对整个产品的理解。做前端也好，后端也罢，最终我们解决的都是“人”的问题 —— 让人更高效、更便捷、更愉快地使用系统。
六、那到底哪个更难？
如果你非要我选一个答案，我只能说：
哪个你不熟，哪个就难。
前端和后端，都有容易入门但难以精进的曲线。你用 jQuery 写个页面不难，但你做一个大型可维护的组件库就难了；你写个 CRUD 接口不难，但你做一个高并发分布式系统就非常难。
真正的难点在于：你愿不愿意持续去深入、去理解、去完善自己的认知体系。
七、写在最后：别问“哪个难”，问“你想走多远”
我见过写前端写到年薪百万的，也见过写后端写到身心俱疲的。
我见过全栈工程师一人顶两人，也见过只会写“增删改查”却年薪 30w 的老哥。
这行最不缺的，就是例外；最需要的，是清醒的自我认知。
别纠结哪个更难，多花时间让自己变强，才是正解。
**你觉得前端难，还是后端难？你有没有在项目里遇到“前后端合作”的那些故事？欢迎评论区聊聊.
来源：juejin.cn/post/7516897654170222592
进入外包，我犯了所有程序员都会犯的错！
前言
前些天有位小伙伴和我吐槽他在外包工作的经历，语气颇为激动又带着深深的无奈。
本篇以他的视角，进入他的世界，看看这一段短暂而平凡的经历。
1. 上岸折戟尘沙
本人男，安徽马鞍山人士，21年毕业于江苏某末流211，在校期间转码。
上网课期间就向往大城市，于是毕业后去了深圳，找到了一家中等IT公司（人数500+）搬砖，住着宝安城中村，来往繁华南山区。
待了三年多，自知买房变深户无望，没有归属感，感觉自己也没那么热爱技术，于是乎想回老家考公务员，希望待在宇宙的尽头。
24年末，匆忙备考，平时工作忙里偷闲刷题，不出所料，笔试卒，梦碎。
2. 误入外包
复盘了备考过程，觉得工作占用时间过多，想要找一份轻松点且离家近的工作，刚好公司也有大礼包的指标，于是主动申请，辞别深圳，前往徽京。
Boss上南京的软件大部分是外包（果然是外包之都），前几年外包还很活跃，这些年外包都沉寂了不少，找了好几个月，断断续续有几个邀约，最后实在没得选了，想着反正就过渡一下挣点钱不寒碜，接受了外包，作为WX服务某为。薪资比在深圳降了一些，在接受的范围内。
想着至少苟着等待下一次考公，因此前期做项目比较认真，遇到问题追根究底，为解决问题也主动加班加点，同为WX的同事都笑话我说比自有员工还卷，我却付之一笑。
直到我经历了几件事，正所谓人教人教不会，事教人一教就会。
3. 我在外包的二三事
有一次，我提出了自有员工设计方案的衍生出的一个问题，并提出拉个会讨论一下，他并没有当场答应，而是回复说：我们内部看看。
而后某天我突然被邀请进入会议，聊了几句，意犹未尽之际，突然就被踢出会议...开始还以为是某位同事误触按钮，然后再申请入会也没响应。
后来我才知道，他们内部商量核心方案，因为权限管控问题，我不能参会。
这是我第一次体会到WX和自有员工身份上的隔阂。
还有一次和自有员工一起吃饭的时候，他不小心说漏嘴了他的公积金，我默默推算了一下他的工资至少比我高了50%，而他的毕业院校、工作经验和我差不多，瞬间不平衡了。
还有诸如其它的团建、夜宵、办公权限、工牌等无一不是明示着你是外包员工，要在外包的规则内行事。
至于转正的事，头上还有OD呢，OD转正的几率都很低，好几座大山要爬呢，别想了。
3. 反求诸己
以前网上看到很多吐槽外包的帖子，还总觉得言过其实，亲身经历了才刻骨铭心。
我现在已经摆正了心态，既来之则安之。正视自己WX的身份，给多少钱干多少活，给多少权利就承担多少义务。
不攀比，不讨好，不较真，不内耗，不加班。
另外每次当面讨论的时候，我都会把工牌给露出来，潜台词就是：快看，我就是个外包，别为难我😔~
另外我现在比较担心的是：
万一我考公还是失败，继续找工作的话，这段外包经历会不会是我简历的污点😢
当然这可能是我个人感受，其它外包的体验我不知道，也不想再去体验了。
对，这辈子和下辈子都不想了。
附南京外包之光，想去或者不想去的伙伴可以留意一下：
来源：juejin.cn/post/7511582195447824438
震惊，中石化将开源组件二次封装申请专利，这波操作你怎么看？
文章推荐：
AI 也救不了的前端坑，你遇到过吗？社区、AI、源码三重排查！
10000+ 个点位轻松展示，使用 Leaflet 实现地图海量标记点聚类
一. 前言
昨天看到了一篇关于 “中石化申请基于 vue 的文件上传组件二次封装方法和装置专利，解决文件上传功能开发繁琐问题” 的新闻。
今天特地在专利系统检索了一下，竟然是真的，令人不禁大跌眼镜！用的全是开源组件，最后还把它们变成了自己的专利！这波操作属实厉害啊！
难道以后要用这种方式上传文件，要交专利费了？哈哈....
说来好笑，有掘友指出有单词拼写错误，我又查看一下专利文件，竟然还真有拼写错误...
二. 了解一下
本专利是通过在 vue 页面中自定义 el-upload 组件和 el-progress 组件的使用，解决了文件上传功能开发步骤繁琐和第三方组件无法满足业务需求的问题，实现了简化开发、提高效率和灵活性的效果。
1. 摘要
本发明提供了一种基于 vue 的文件上传组件的二次封装方法和装置，解决了针对于文件上传功能的开发步骤繁琐，复杂，且上传功能的第三方组件无法完全满足业务需求的问题。
该基于 vue 的文件上传组件的二次封装方法包括：在 vue 页面中创建 el‑upload 组件和 el‑progress 组件；
基于所述 el‑upload 组件获取目标上传文件的大小，并判断所述目标上传文件的大小是否符合上传标准；若是，上传所述目标上传文件，并基于所述 el‑progress 组件获取上传进度；上传完成后，对上传的所述目标上传文件进行预处理并存储；
对存储的所述目标上传文件进行封装，并获得 vue 组件。
技术流程图：
二次封装装置模块：
2. 解决的技术问题
现有技术中文件上传功能的开发步骤繁琐复杂，第三方组件无法完全满足业务需求。
3. 采用的技术手段
通过在 vue 页面中引入 el-upload 组件和 el-progress 组件，自定义上传方法和进度条绑定，获取文件大小和上传进度，进行预处理和存储，并将其封装成可重复使用的 vue 组件。
4. 产生的技术功效
简化了文件上传功能的开发步骤，节省了开发时间和效率，避免了代码沉冗，降低了后期维护成本，并提高了文件上传功能的灵活性。
三. 实现一下
这种简单的上传文件+上传进度显示不是最基本的业务封装吗？相信这是每个前端开发工程师必备的基础技能。
1. el-upload + el-progress 组合
- el-upload 负责文件选择、上传。
- el-progress 负责展示上传进度。
2. 文件大小校验
- 使用 el-upload 的
before-upload钩子，判断文件大小是否符合标准。
3. 上传进度获取
- 使用 el-upload 的
on-progress钩子，实时更新进度条。
4. 上传完成后的预处理与存储
- 上传完成后，触发自定义钩子（如
beforeStore、onStore），进行预处理和存储。
5. 封装为 Vue 组件
- 通过 props、emits、插槽等方式，暴露灵活的接口，便于业务页面集成。
都懒得自己动手，让 Cursor 来实现一下。Cursor 还是一如既往的强大，基本上一次询问就能成功！我表示 Cursor 在手，天下我有！
UploaderWrapper 自定义组件：
<script lang="ts" setup>
import { computed, ref } from 'vue';
import { ElButton, ElMessage, ElProgress, ElUpload } from 'element-plus';
interface UploadProps {
maxSize?: number; // MB
action: string;
accept?: string;
beforeStore?: (file: File) => Promise<File>;
onStore?: (file: File) => Promise<void>;
onError?: (error: Error) => void;
showFileList?: boolean;
multiple?: boolean;
limit?: number;
}
const props = withDefaults(defineProps<UploadProps>(), {
maxSize: 10,
accept: '*',
beforeStore: async (file: File) => file,
onStore: async () => {},
onError: () => {},
showFileList: true,
multiple: false,
limit: 1,
});
const emit = defineEmits<{
(e: 'uploadSuccess', file: File): void;
(e: 'uploadError', error: Error): void;
}>();
const uploadPercent = ref(0);
const uploading = ref(false);
const fileList = ref<any[]>([]);
const isUploading = computed(() => uploading.value);
function handleExceed(files: File[]) {
ElMessage.warning(`最多只能上传 ${props.limit} 个文件`);
}
function beforeUpload(file: File) {
const isLtMax = file.size / 1024 / 1024 < props.maxSize;
if (!isLtMax) {
ElMessage.error(`文件大小不能超过 ${props.maxSize}MB!`);
return false;
}
if (props.accept !== '*') {
const extension = file.name.split('.').pop()?.toLowerCase();
const acceptTypes = props.accept.split(',').map((type) => type.trim());
const isValidType = acceptTypes.some((type) => {
if (type.startsWith('.')) {
return `.${extension}` === type;
}
return file.type.startsWith(type);
});
if (!isValidType) {
ElMessage.error(`只能上传 ${props.accept} 格式的文件!`);
return false;
}
}
return true;
}
function handleProgress(event: any) {
uploading.value = true;
uploadPercent.value = Math.round(event.percent);
}
async function handleSuccess(response: any, file: any) {
try {
uploading.value = false;
uploadPercent.value = 100;
// 预处理
const processedFile = await props.beforeStore(file.raw);
// 存储
await props.onStore(processedFile);
ElMessage.success('上传并处理成功');
emit('uploadSuccess', processedFile);
} catch (error) {
handleError(error as Error);
}
}
function handleError(error: Error) {
uploading.value = false;
uploadPercent.value = 0;
ElMessage.error('上传失败');
props.onError(error);
emit('uploadError', error);
}
function handleRemove(file: any) {
const index = fileList.value.indexOf(file);
if (index !== -1) {
fileList.value.splice(index, 1);
}
}
</script>
<template>
<div class="file-uploader">
<ElUpload
:action="action"
:before-upload="beforeUpload"
:on-progress="handleProgress"
:on-success="handleSuccess"
:on-error="handleError"
:limit="limit"
:on-exceed="handleExceed"
:show-file-list="showFileList"
:multiple="multiple"
:accept="accept"
v-model:file-list="fileList"
:on-remove="handleRemove"
>
<template #trigger>
<ElButton type="primary"> 选择文件上传 </ElButton>
</template>
<template #tip>
<div class="el-upload__tip">
支持的文件类型: {{ accept }}，单个文件不超过 {{ maxSize }}MB
</div>
</template>
</ElUpload>
<ElProgress
v-if="isUploading"
:percentage="uploadPercent"
:status="uploadPercent === 100 ? 'success' : ''"
class="mt-4"
/>
</div>
</template>
<style scoped>
.file-uploader {
width: 100%;
}
.el-upload__tip {
font-size: 12px;
color: #606266;
margin-top: 8px;
}
</style>
使用方式：
<script lang="ts" setup>
import { ElCard } from 'element-plus';
import UploaderWrapper from './UploaderWrapper.vue';
const beforeStore = async (file: File) => {
// 这里可以做预处理，比如图片压缩、格式转换等
return file;
};
const onStore = async (file: File) => {
// 这里可以做存储，比如保存到本地等
// 处理存储逻辑
};
</script>
<template>
<ElCard class="mb-5 w-80">
<template #header> 文件上传演示 </template>
<UploaderWrapper
action="/api/upload"
:max-size="5"
:before-store="beforeStore"
:on-store="onStore"
/>
</ElCard>
</template>
效果如下所示：
声明：“代码仅供演示，不要使用，以免有专利侵权风险，慎重！”
四. 思考一下
从开发者的角度来看，这个专利事件是否能给我们带来了一些值得思考影响和启示：
- 技术创新的边界问题
- 使用开源组件进行二次封装是否应该被授予专利？
- 是否对开源社区的发展可能产生负面影响？
- 对日常开发的影响
- 如果专利获得授权，其他公司使用类似的文件上传组件封装方案是否可能面临法律风险？
- 开发者是否需要寻找替代方案或支付专利费用？
- 对开源社区的影响
- 可能打击开发者对开源项目的贡献热情，自己辛苦开源项目为别人做了嫁衣？
- 是否会影响开源组件的使用和二次开发
- 可能导致更多公司效仿，将开源组件的二次封装申请专利，因为毕竟专利对公司的招投标挺大的
五. 后记
“中石化作为传统能源企业，都能积极拥抱前端技术，还将内部技术方案申请专利，体现了他们对知识产权的重视？”
那我们是不是要在技术创新和知识产权保护之间找到平衡点，既要保护创新，又不能阻碍技术的发展。
而作为开发者的我们呢？这么简单的封装都能申请专利成功的话，那么...，大家有什么想法，是不是现在强的可怕？哈哈...
专利来源于国家知识产权局
申请公布号：CN120122937A
来源：juejin.cn/post/7514858513442078754
