specifies a base path for resolving relative URLs to assets such as images, scripts, and style sheets. For example, given the <base href="/my/app/">
, the browser resolves a URL such as some/place/foo.jpg
into a server request for my/app/some/place/foo.jpg
. During navigation, the Angular router uses the base href as the base path to component, template, and module files.
HTML 中的<base href="/..."/>用于指定一个解析相对路径的基地址,如图片、脚本和样式表。 比如,指定 <base href="/my/app/">
时,浏览器就会把 some/place/foo.jpg
这样的 URL 解析成到 my/app/some/place/foo.jpg
的服务端请求。 在浏览期间,Angular 路由器会使用base href作为组件、模板和模块文件的基地址。
See also the APP_BASE_HREF alternative.
参见另一种备选方案APP_BASE_HREF。
In development, you typically start the server in the folder that holds index.html
. That's the root folder and you'd add <base href="/">
near the top of index.html
because /
is the root of the app.
在开发期间,你通常会在 index.html
所在的目录中启动服务器。这个目录就是根目录,因为 /
就是本应用的根,所以你要在 index.html
的顶部添加 <base href="/">
。
But on the shared or production server, you might serve the app from a subfolder. For example, when the URL to load the app is something like http://www.mysite.com/my/app/
, the subfolder is my/app/
and you should add <base href="/my/app/">
to the server version of the index.html
.
但是在共享服务器或生产服务器上,你可能得从子目录下启动服务器。 比如,当加载本应用的 URL 是 http://www.mysite.com/my/app/
时,子目录就是 my/app/
,而你就要在服务器版的 index.html
中添加 <base href="/my/app/">
。
When the base
tag is mis-configured, the app fails to load and the browser console displays 404 - Not Found
errors for the missing files. Look at where it tried to find those files and adjust the base tag appropriately.
当没有配置 base
标签时,加载应用就会失败,浏览器的控制台中会为这些缺失的文件显示一些 404 - Not Found
错误。 看看浏览器试图从哪里找这些文件,然后调整出合适的 base 标签。
You'll probably prefer ng build
for deployments.
你会更喜欢用 ng build
进行部署。
The ng build command is intended for building the app and deploying the build artifacts elsewhere. The ng serve command is intended for fast, local, iterative development.
ng build 命令的设计意图是构建该应用,并且把构建成果部署到别处。 而ng serve 命令的设计意图是快速进行本地的迭代式开发。
Both ng build
and ng serve
clear the output folder before they build the project. The ng build
command writes generated build artifacts to the output folder. The ng serve
command does not. It serves build artifacts from memory instead for a faster development experience.
在开始构建项目之前,ng build
和 ng serve
都会清空输出文件夹。 ng build
命令会把生成的构建成果写入输出文件夹中,但 ng serve
命令并不会如此。 它会用内存中的构建成果提供服务,以获得更快速的开发体验。
The output folder is dist/
by default. To output to a different folder, change the outputPath
in angular.json
.
默认的输出文件夹是 dist/
。 要输出到其它文件夹中,请修改 angular.json
中的 outputPath
。
The ng serve
command builds, watches, and serves the application from a local CLI development server.
ng serve
命令会构建、监听并使用本地的 CLI 开发服务器作为服务器。
The ng build
command generates output files just once and does not serve them. The ng build --watch
command will regenerate output files when source files change. This --watch
flag is useful if you're building during development and are automatically re-deploying changes to another server.
ng build
命令只会生成一次这些输出文件,而不会用它们提供服务。 ng build --watch
命令会在源码变化的时候重新生成输出文件。 当你在开发期间需要不断构建并自动把修改后的版本发布到另一台服务器的时候,这个 --watch
标志会很有用。
See the CLI build
topic for more details and options.
参见 CLI 中的 build
主题以了解详情以及其它选项。
This section covers changes you may have make to the server or to files deployed to the server.
这一节涵盖了你可能对服务器或准备部署到服务器的文件要做的那些修改。
index.html
linkindex.html
作为后备页面linkAngular apps are perfect candidates for serving with a simple static HTML server. You don't need a server-side engine to dynamically compose application pages because Angular does that on the client-side.
Angular 应用很适合用简单的静态 HTML 服务器提供服务。 你不需要服务端引擎来动态合成应用页面,因为 Angular 会在客户端完成这件事。
If the app uses the Angular router, you must configure the server to return the application's host page (index.html
) when asked for a file that it does not have.
如果该应用使用 Angular 路由器,你就必须配置服务器,让它对不存在的文件返回应用的宿主页(index.html
)。
A routed application should support "deep links". A deep link is a URL that specifies a path to a component inside the app. For example, http://www.mysite.com/heroes/42
is a deep link to the hero detail page that displays the hero with id: 42
.
带路由的应用应该支持“深链接”。 所谓深链接就是指一个 URL,它用于指定到应用内某个组件的路径。 比如,http://www.mysite.com/heroes/42
就是一个到英雄详情页面的深链接,用于显示 id: 42
的英雄。
There is no issue when the user navigates to that URL from within a running client. The Angular router interprets the URL and routes to that page and hero.
当用户从运行中的客户端应用导航到这个 URL 时,这没问题。 Angular 路由器会拦截这个 URL,并且把它路由到正确的页面。
But clicking a link in an email, entering it in the browser address bar, or merely refreshing the browser while on the hero detail page — all of these actions are handled by the browser itself, outside the running application. The browser makes a direct request to the server for that URL, bypassing the router.
但是,当从邮件中点击链接或在浏览器地址栏中输入它或仅仅在英雄详情页刷新下浏览器时,所有这些操作都是由浏览器本身处理的,在应用的控制范围之外。 浏览器会直接向服务器请求那个 URL,路由器没机会插手。
A static server routinely returns index.html
when it receives a request for http://www.mysite.com/
. But it rejects http://www.mysite.com/heroes/42
and returns a 404 - Not Found
error unless it is configured to return index.html
instead.
静态服务器会在收到对 http://www.mysite.com/
的请求时返回 index.html
,但是会拒绝对 http://www.mysite.com/heroes/42
的请求, 并返回一个 404 - Not Found
错误,除非,它被配置成了返回 index.html
。
There is no single configuration that works for every server. The following sections describe configurations for some of the most popular servers. The list is by no means exhaustive, but should provide you with a good starting point.
没有一种配置可以适用于所有服务器。 后面这些部分会描述对常见服务器的配置方式。 这个列表虽然不够详尽,但可以为你提供一个良好的起点。
Lite-Server: the default dev server installed with the Quickstart repo is pre-configured to fallback to index.html
.
Lite-Server是"快速上手"仓库中安装的默认开发服务器,它被预先配置为回退到 index.html
。
Webpack-Dev-Server: setup the historyApiFallback
entry in the dev server options as follows:
Webpack-Dev-Server在开发服务器的配置中设置了 historyApiFallback
,代码如下:
Apache: add a rewrite rule to the .htaccess
file as shown (https://ngmilk.rocks/2015/03/09/angularjs-html5-mode-or-pretty-urls-on-apache-using-htaccess/):
Apache:在 .htaccess
文件中添加一个重写规则, 代码如下(出处):
# If the requested resource doesn't exist, use index.html RewriteRule ^ /index.html
NGinx: use try_files
, as described in Front Controller Pattern Web Apps, modified to serve index.html
:
NGinx:使用 try_files
指向 index.html
,详细描述见Web 应用的前端控制器模式。
IIS: add a rewrite rule to web.config
, similar to the one shown here:
IIS:往 web.config
中添加一条重写规则,类似于这里:
GitHub Pages: you can't directly configure the GitHub Pages server, but you can add a 404 page. Copy index.html
into 404.html
. It will still be served as the 404 response, but the browser will process that page and load the app properly. It's also a good idea to serve from docs/
on master and to create a .nojekyll
file
GitHub 页面服务:你没办法直接配置 Github 的页面服务,但可以添加一个 404 页,只要把 index.html
复制到 404.html
就可以了。 它仍然会给出一个 404 响应,但是浏览器将会正确处理该页,并正常加载该应用。 使用在主分支的 docs/
下启动服务 并创建一个 .nojekyll
文件也是一个好办法。
Firebase hosting: add a rewrite rule.
Firebase 主机服务:添加一条重写规则。
Angular developers may encounter a cross-origin resource sharing error when making a service request (typically a data service request) to a server other than the application's own host server. Browsers forbid such requests unless the server permits them explicitly.
Angular 开发者在向与该应用的宿主服务器不同域的服务器发起请求时,可能会遇到一种跨域资源共享(CORS)错误。 浏览器会阻止该请求,除非得到那台服务器的明确许可。
There isn't anything the client application can do about these errors. The server must be configured to accept the application's requests. Read about how to enable CORS for specific servers at enable-cors.org.
客户端应用对这种错误无能为力。 服务器必须配置成可以接受来自该应用的请求。 要了解如何对特定的服务器开启 CORS,参见enable-cors.org。