🔥 后端开发的10大"致命陷阱"：90%程序员中招的隐蔽错误清单（2025避坑指南）

大家好，这里是架构资源栈！点击上方关注，添加“星标”，一起学习大厂前沿架构！

缺乏安全感

我有意把这一点作为第一点。作为前端开发人员，你构建了系统。

当然，该系统得到保护。我不敢有多少人仍然需要重视应用程序中的CORS或速率限制等安全功能，但不幸的是，这种情况确实发生了。这些主题对于保护您的系统漏洞攻击至关重要。下面，我推出了测试系统时需要用到的重要主题清单。

安全检查表：

类别	安全措施
网络	启用 HSTS
	使用 SSL
	检查SSL版本、算法、密钥长度
身份验证和会话	使用安全 Cookie
	对密码实施SHA256加密
授权和访问控制	实施CSRF
	绕过测试表单上的授权架构
输入和数据验证	测试 HTML 和 SQL 注入
	测试文件名处理
客户端安全	检查客户端代码中的敏感数据
	我们使用 reCAPTCHA

数据库设计。

缺乏合适的索引：开发人员有时会忘记添加索引或添加索引过多。两者都不好。你应该找到正确的平衡点。如果没有索引，查询会连接得很慢，数据库会因为扫描整个 表。另外，过多的索引会增加存储使用量并减慢读取操作。所以要小心。

我们的索引：建议经常查询的列添加。

一开始就忽略了可扩展性和未来增长：许多开发人员根据当前需求设计数据库，而不考虑未来增长。这会导致分区不足、数据类型选择不当以及以后难以处理高流量负载等问题。

我们的建议：您可能认为在数据库设计上花费大量的时间是不必要的，但事实并非如此。规划需要您考虑当前的需求和未来的增长。与前面的例子一样，这里您也需要寻求适当的平衡。我们建议使用以下公式：

currentNeeds = 10GB // For example

myDatabase = currentNeeds x 0.20 // So add 20%

实际解释：

此公式可帮助您的规划数据库，不仅考虑当前需求，还考虑未来增长。

currentNeeds->这是您的数据库当前需要多少空间或多少资源。将其视为您现有数据的大小或当前操作所需的容量。

myDatabase->这是数据库的最终大小或容量，它是您当前需求和额外法兰克福

（20％）的组合。

因此，您不应只为数据库分配10GB，而应分配计划12GB。这20%的额外空间可用于增长，从而确保您的数据库不会在您随时间添加更多数据或功能时锻炼空间。

其他注意事项：

列选择：使用适当的数据类型。例如，对于VARCHAR(255)永远不会超过100个字符的字段，不要使用，而应使用VARCHAR(100)节省空间。

增长监控：持续监控数据库的增长情况。您可以alerts根据磁盘使用情况、表大小和行数进行设置。您可以在此处找到有关数据库分析的更多信息。

通过提前考虑并分配 20% 以上的生长空间，您可以避免与数据库性能相关的潜在问题以及间隙重新设计的需要。

没有考虑预算

缓存是头部开发的一个重要方面，但它经常被忽视。

为什么重要：

如果没有缓存，随着越来越多的用户访问您的应用，您的系统可能会变慢。每次向服务器发出请求时，系统都必须完全处理该请求，这可能会导致延迟和性能问题，您肯定不希望出现这种情况。

我们的建议：使用Redis或 Mem****cached 等内存数据存储来存储访问频繁的数据（如产品详细信息或用户会话）。此外，请记住设置间隔时间和服务器故障策略，以确保使用最新的数据刷新磁盘。

硬件变量值

直接在代码中对连接字符串、API密钥和其他配置参数等值进行硬编码是一个常见且严重的错误。

为什么它不好：

这使得代码更难以维护。

在代码中暴露的敏感信息（例如API密钥）可能会导致安全问题。

如果需要更改配置值，则必须搜索整个代码库并在所有位置更新它。糟糕❌

public class UserService

{

public void ConnectToDatabase()

{

// Hardcoded connection string, making it difficult to change or string connectionString = "Server=myServerAddress;Database=myData

// Code to establish a connection...

}

}

好✅

public class UserService

{

public void ConnectToDatabase()

{

// Use environment variable to get the connection string securely string connectionString = Environment.GetEnvironmentVariable("DB_

if (string.IsNullOrEmpty(connectionString))

{

throw new Exception("Database connection string not found.");

}

// Code to establish a connection...

}

}

没有正确使用版本控制

如果你写了这样的提交信息：

git commit -m "fix"

git commit -m "fix v1.2"

git commit -m "fix something" git commit -m "fix bug"

git commit -m "change"

git commit -m "optimization"

别用力。

为什么它不好：

其他人员不知道您在该开发中做了什么，而需要检查更改的文件，这需要时间。 通过这样做，您可以轻松获得大量具有相同/相似消息的工作。

当您需要恢复到旧的提交时，通过查看上面类似的提交日志，您无法知道要重置到哪一个。

fix例如，将来您将不知道应用程序的哪一部分被提交。

好✅

git commit -m "chore: modify README.md file"

git commit -m "fix: user validation not working"

git commit -m "feat: user validation of create form"

git commit -m "docs: add our team page"

git commit -m "ui: add image swiper on the home page"

附加提示：始终使用当前状态编写提交信息。因此不要changed写成。您可以在此处

change了解常规提交。

没有区分业务逻辑、基础设施和其他问题

实验室开发人员常犯的一个错误是没有在代码库中正确分离关注点。具体来说，就是将业务逻辑、基础架构代码、数据访问和 API 路由混合到单个类或模块中。

为什么它不好：

紧密耦合：当业务逻辑与基础设施代码（如数据库操作、第三方服务集成等）紧密耦 合时，测试和维护会变得困难。基础设施中的一个小变化可能会破坏你的业务逻辑。

难以扩展：随着代码库的增长，缺乏分离会导致更大的复杂性，使得扩展应用程序和

在不破坏现有功能的情况下开发新功能变得更加困难。

我们的建议是：将这些关注点拆分成不同的层或组件。这符合关注点分离（SoC）原则，并可提高竞争力、可扩展性和可维护性。

译文：清洁架构、六边形架构、分层架构、微服务架构、CQRS、事件驱动架构、领域驱动架构

结论

在您继续开发旅程时，请记住这些，并记住：从长期提示来看，测试、优化和遵循最佳实践俱乐部回馈！

如果我忘记了什么，或者你喜欢这篇文章，请在下面留言💬感谢阅读：)

---