关于你提到的文件夹:

/libs通常用于自定义类/函数/模块 /vendor或/support包含第三方库(作为git添加) 子模块时使用git作为源代码控制) /spec包含BDD测试的规范。 /tests包含应用程序的单元测试(使用测试 框架,看到 这里)

注意:/vendor和/support都已弃用，因为NPM引入了干净的包管理。建议使用NPM和包来处理所有第三方依赖关系。json文件

当构建一个相当大的应用程序时，我建议使用以下额外的文件夹(特别是如果你使用某种MVC- / ORM-Framework，如express或mongoose):

/models contains all your ORM models (called Schemas in mongoose) /views contains your view-templates (using any templating language supported in express) /public contains all static content (images, style-sheets, client-side JavaScript) /assets/images contains image files /assets/pdf contains static pdf files /css contains style sheets (or compiled output by a css engine) /js contains client side JavaScript /controllers contain all your express routes, separated by module/area of your application (note: when using the bootstrapping functionality of express, this folder is called /routes)

我已经习惯了用这种方式组织我的项目，我认为它效果很好。

基于coffeescript的Express应用程序更新(使用连接资产):

/app contains your compiled JavaScript /assets/ contains all client-side assets that require compilation /assets/js contains your client-side CoffeeScript files /assets/css contains all your LESS/Stylus style-sheets /public/(js|css|img) contains your static files that are not handled by any compilers /src contains all your server-side specific CoffeeScript files /test contains all unit testing scripts (implemented using a testing-framework of your choice) /views contains all your express views (be it jade, ejs or any other templating engine)

在GitHub上有一个讨论，因为一个类似的问题: https://gist.github.com/1398757

你可以使用其他项目进行指导，在GitHub中搜索:

js -在我看来，似乎有一个特定的结构不适合每个项目; 更轻-一个更简单的结构，但缺乏一点组织;

最后，在一本书(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文件夹。

这是间接的回答，就文件夹结构本身而言，关系很大。

几年前，我也有同样的问题，采取了一个文件夹结构，但后来不得不做了很多目录移动，因为文件夹的目的与我在互联网上读到的不同，也就是说，一个特定的文件夹对不同的人在一些文件夹上有不同的意义。

现在，已经做了多个项目，除了在所有其他答案中解释，关于文件夹结构本身，我强烈建议遵循Node.js本身的结构，可以在https://github.com/nodejs/node上看到。它提供了所有文件的详细信息，比如linter和其他文件，它们有什么文件和文件夹结构以及在哪里。有些文件夹有一个README，解释文件夹中有什么。

从上面的结构开始是很好的，因为有一天会有一个新的需求，但你将有一个改进的空间，因为它已经被Node.js本身维护了很多年。

需要注意的是，对于什么是最佳方法并没有共识，相关框架通常不会强制执行或奖励某些结构。

我发现这是一个令人沮丧和巨大的开销，但同样重要。这是一种风格指南问题的低调版本(但在我看来更重要)。我喜欢指出这一点，因为答案是一样的:只要你使用的结构是明确的和连贯的，它就不重要。

所以我建议你找一份你喜欢的全面指南，并明确说明这个项目是基于这个指南的。

这并不容易，尤其是对新手来说!准备好花几个小时研究。您会发现大多数指南都推荐类似mvc的结构。虽然几年前这可能是一个可靠的选择，但现在情况未必如此。举个例子，这是另一种方法。

假设我们谈论的是web应用程序和构建api:

一种方法是根据特征对文件进行分类。说明:

我们正在开发一个图书馆应用程序。在应用程序的第一个版本中，用户可以:

搜索图书，查看图书元数据 搜索作者，看他们的书

在第二个版本中，用户还可以:

创建帐户并登录 贷款/借书

在第三个版本中，用户还可以:

保存他们想要阅读的书单/标记收藏夹

首先我们有以下结构:

books
  └─ entities
  │   └─ book.js
  │   └─ author.js
  │
  └─ services
  │   └─ booksService.js
  │   └─ authorsService.js
  │
  └─ repositories
  │   └─ booksRepository.js
  │   └─ authorsRepository.js
  │
  └─ controllers
  │   └─ booksController.js
  │   └─ authorsController.js
  │
  └─ tests
      └─ ...

然后我们添加用户和贷款功能:

user
  └─ controllers
  └─ entities
  └─ services
  └─ ...

loan
  └─ controllers
  └─ ...

然后是收藏功能:

favorites
  └─ controllers
  └─ entities
  └─ ...

对于任何新开发人员来说，如果有任何书籍被标记为收藏，那么图书搜索也应该返回信息，这很容易看出他/她应该在代码的哪里查找。

然后，当产品负责人突然出现并惊呼应该完全删除收藏夹功能时，就很容易删除它了。

只需从GitHub克隆回购

https://github.com/abhinavkallungal/Express-Folder-Structure

这是一个node.js express.js项目的基本结构 已经设置MongoDB作为数据库，hbs作为视图引擎，nodemon也， 这样你就可以轻松地设置node js express项目

第一步:下载或克隆回购 步骤2:在任何代码编辑器中打开 步骤3:在文件夹路径上打开终端 第四步:在终端npm start中运行注释 第五步:开始编码