Answers:
关于您提到的文件夹：
/libs 通常用于自定义 classes/functions/modules/vendor或/support包含第三方库（使用git作为源代码管理时添加为git子模块）/spec 包含BDD测试规范。/tests包含应用程序的单元测试（使用测试框架，请参见
此处）注意：自NPM引入了干净的程序包管理以来，/vendor和/support都已弃用。建议使用NPM和package.json文件处理所有第三方依赖关系
在构建较大的应用程序时，我建议使用以下附加文件夹（尤其是在使用某种MVC- / ORM-Framework（例如express或mongoose）时）：
/models包含您所有的ORM模型（Schemas在猫鼬中称为）/views 包含您的视图模板（使用express中支持的任何模板语言）/public 包含所有静态内容（图像，样式表，客户端JavaScript）
/assets/images 包含图像文件/assets/pdf 包含静态pdf文件/css 包含样式表（或CSS引擎编译的输出）/js 包含客户端JavaScript/controllers包含您所有的Express路由，按应用程序的模块/区域分隔（注意：使用express的引导功能时，此文件夹称为/routes）我习惯了以这种方式组织项目，我认为效果很好。
基于CoffeeScript的Express应用程序的更新（使用connect-assets）：
/app 包含您已编译的JavaScript/assets/ 包含所有需要编译的客户端资产
/assets/js 包含您的客户端CoffeeScript文件/assets/css 包含您所有的LESS / Stylus样式表/public/(js|css|img) 包含没有任何编译器处理的静态文件/src 包含所有服务器端特定的CoffeeScript文件/test 包含所有单元测试脚本（使用您选择的测试框架来实现）/views 包含您所有的表达意见（无论是jade，ejs还是任何其他模板引擎）由于存在与此问题类似的问题，因此在GitHub上进行了讨论：https : //gist.github.com/1398757
您可以使用其他项目作为指导，在GitHub中搜索：
最后，在书中（http://shop.oreilly.com/product/0636920025344.do）提出了以下结构：
├── index.html
├── js/
│ ├── main.js
│ ├── models/
│ ├── views/
│ ├── collections/
│ ├── templates/
│ └── libs/
│ ├── backbone/
│ ├── underscore/
│ └── ...
├── css/
└── ...我的项目架构中的更多示例可以在这里看到：
├── Dockerfile
├── README.md
├── config
│ └── production.json
├── package.json
├── schema
│ ├── create-db.sh
│ ├── db.sql
├── scripts
│ └── deploy-production.sh
├── src
│ ├── app -> Containes API routes
│ ├── db -> DB Models (ORM)
│ └── server.js -> the Server initlializer.
└── test基本上，逻辑应用程序分离到SRC目录中的DB和APP文件夹。
src或该前端应用程序是否获得了自己的文件夹（具有自己的package.json相似文件夹结构）？
这是间接的答案，关于文件夹结构本身，非常相关。
几年前，我有一个相同的问题，采用了文件夹结构，但后来不得不做很多目录移动，因为该文件夹的目的与我在互联网上阅读的目的不同，即特定文件夹的功能不同人在某些文件夹上的含义不同。
现在，除了对所有其他答案进行解释之外，在文件夹结构本身上做了多个项目，我强烈建议遵循Node.js本身的结构，该结构可以在以下网址查看：https : //github.com/ nodejs / node。它详细介绍了所有内容，例如linters和其他文件，它们具有的文件和文件夹结构以及位置。有些文件夹具有自述文件，说明该文件夹中的内容。
从上面的结构开始是一个好习惯，因为有一天会有新的要求出现，但是您将有一个改进的余地，因为Node.js本身已经被它所遵循，并且已经维护了很多年。
希望这可以帮助。
假设我们正在谈论Web应用程序和构建API：
一种方法是按功能对文件进行分类，非常类似于微服务架构的外观。我认为最大的胜利是，可以轻松查看哪些文件与应用程序功能相关。
最好的说明方式是通过一个示例：
我们正在开发一个图书馆应用程序。在该应用程序的第一个版本中，用户可以：
在第二个版本中，用户还可以：
在第三个版本中，用户还可以：
首先，我们具有以下结构：
books
├─ controllers
│ ├─ booksController.js
│ └─ authorsController.js
│
└─ entities
├─ book.js
└─ author.js然后，我们添加用户和贷款功能：
user
├─ controllers
│ └─ userController.js
├─ entities
│ └─ user.js
└─ middleware
└─ authentication.js
loan
├─ controllers
│ └─ loanController.js
└─ entities
└─ loan.js然后收藏夹功能：
favorites
├─ controllers
│ └─ favoritesController.js
└─ entities
└─ favorite.js对于任何需要完成添加任务的新开发人员，如果书籍被标记为收藏，书籍搜索还应该返回信息，这很容易看出他/她应该在代码中查找的位置。
然后，当产品负责人进入并宣称应该完全删除“收藏夹”功能时，很容易将其删除。