1. WEB項目部署，網頁瀏覽器未響應問題
1、首先說您描述的信息內容不夠，而且這個原因有很多種；
2、不論您用什麼語音進行的開發，都需要有日誌輸出，可以通過日誌輸出查看一下是不是程序或者資料庫的問題；
3、web部署不論是linux還是windows環境都要保證基礎環境的可用性，請檢查防火牆、網路、以及apache/nginx等服務的可用性；
4、至於問題中提到的死循環需要開發人員自己進行檢測，系統資源可以通過top等命令查看或者聯系運維同學。
2. linux測試伺服器如何部署web項目
使用tomcat, nginx ,apache之類的app就可以部署web項目
如何部署可以參考相關app的官方文檔。
3. 如何獲取web應用的部署路徑
在java中獲得文件的路徑在我們做上傳文件操作時是不可避免的。
web 上運行
1:this.getClass().getClassLoader().getResource("/").getPath();
this.getClass().getClassLoader().getResource("").getPath(); 得到的是 ClassPath的絕對URI路徑。
如：/D:/jboss-4.2.2.GA/server/default/deploy/hp.war/WEB-INF/classes/
System.getProperty("user.dir");
this.getClass().getClassLoader().getResource(".").getPath(); 得到的是 項目的絕對路徑。
如：/D:/jboss-4.2.2.GA/server/default/deploy/hp.war
2:this.getClass().getResource("/").getPath();
this.getClass().getResource("").getPath(); 得到的是當前類 文件的URI目錄。
如：/D:/jboss-4.2.2.GA/server/default/deploy/hp.war/WEB-INF/classes/com/jebel/helper/
this.getClass().getResource(".").getPath(); X 不 能運行
3:Thread.currentThread().getContextClassLoader().getResource("/").getPath()
Thread.currentThread().getContextClassLoader().getResource("").getPath() 得到的是 ClassPath的絕對URI路徑。
如：/D:/jboss-4.2.2.GA/server/default/deploy/hp.war/WEB-INF/classes/
Thread.currentThread().getContextClassLoader().getResource(".").getPath() 得到的是 項目的絕對路徑。
如：/D:/jboss-4.2.2.GA/server/default/deploy/hp.war
在本地運行中
1：this.getClass().getClassLoader().getResource("").getPath();
this.getClass().getClassLoader().getResource(".").getPath(); 得到的是 ClassPath的絕對URI路徑。
如:/D:/myProjects/hp/WebRoot/WEB-INF/classes
this.getClass().getClassLoader().getResource(".").getPath(); X 不 能運行
2：this.getClass().getResource("").getPath();
this.getClass().getResource(".").getPath(); 得到的是當前類 文件的URI目錄。
如：/D:/myProjects/hp/WebRoot/WEB-INF/classes/com/jebel/helper/
/D:/myProjects/hp/WebRoot/WEB-INF/classes/ 得到的是 ClassPath的絕對URI路徑。
如:/D:/myProjects/hp/WebRoot/WEB-INF/classes
3：Thread.currentThread().getContextClassLoader().getResource(".").getPath()
Thread.currentThread().getContextClassLoader().getResource("").getPath() 得到的是 ClassPath的絕對URI路徑。。
如:/D:/myProjects/hp/WebRoot/WEB-INF/classes
Thread.currentThread().getContextClassLoader().getResource("/").getPath() X 不 能運行
最後
在Web應用程序中，我們一般通過ServletContext.getRealPath（"/"）方法得到Web應用程序的根目錄的絕對路徑。
還有request.getContextPath(); 在Weblogic中要用request.getServletContext().getContextPath();但如果打包成war部署到Weblogic伺服器，項目內部並沒有文件結構的概念，用這種方式是始終得到null，獲取不到路徑，目前還沒有找到具體的解決方案。
4. web站點部署是什麼意思,
Web站點部署就是指將web項目部署到不同web伺服器(tomcat或weblogic,tomcat是目前用的最多的一個客服伺服器)上,在本地測試外網訪問等可以直接訪問,
5. Docker部署WEB 應用
1、環境：阿里雲伺服器
2、CentOS7系統
3、Docker成功部署
這里前提docker 已經成功部署啦，現有有一個簡單的測試案例，在docker上部署一個應用從而訪問web。
接下來讓我們嘗試使用 docker 構建一個 web 應用程序。
我們將在docker容器中運行一個 Python Flask 應用來運行一個web應用。
通過 -p 參數來設置一樣的埠：
docker ps 查看正在運行的容器
容器內部的 5000 埠映射到我們本地主機的 5000 埠上。
這時我們可以通過瀏覽器訪問WEB應用
發現 訪問失敗
指定外網埠為5000，
1. 本地測試能否打開測試頁
本地沒有問題。
2. 瀏覽器中訪問
在任意一台電腦上輸入公網IP+埠號 (此埠號為運行WEB應用時指定的埠號5000) 如我的阿里雲公網IP為123.11.11.11 此時在任意一台有網路的瀏覽器地址欄輸入公網IP：http://123.11.11.11:5000 應該會出現測試頁
但現在出現如下圖所示：
顯示打不開
查啦大量資料，以前曾經也解決過，一定弄明白自已購買的地區後，再去設置安全組的配置規則。
***1. 登錄阿里雲管理控制台****
2.找到雲伺服器ECS-概覽
5. 手動添加埠5000
6. 最後保存，再從瀏覽器地址欄輸入公網IP加埠號5000成功顯示測試頁如圖：
6. 如何部署python web程序
Python Web 程序的部署方案
綜合而言, 高性能的Python web站點部署方式首推 nginx + uwsgi
apache + mod_wsgi 是簡單穩定但性能一般的方式
API伺服器 可以直接使用tornado或者gevent
mod_python
非常原始的cgi模式部署python已經沒有什麼好介紹了。對於不太追求性能的管理系統和網站來說，使用 Apache 部署是一個不錯的選擇。較早的時候，使用 mode_python 部署python的web應用十分流行,在Django 0.96 的時候官方文檔甚至推薦這種方式。
它將Python解釋器嵌入到Apache server,以提供一個訪問Apache server內部的介面。mod_python 在現在看來性能是不佳的，每一個http請求 mod_python 都會由一個進程初始化python解釋器、載入代碼、執行、然後銷毀進程。
mod_wsgi
如果非要用Apache來部署python應用，mod_wsgi是一個更好的選擇。WSGI 全稱是 Web Server Gateway Interface ,由 PEP-333 定義。 基本上所有的python web框架都實現了wsgi介面，用mod_wsgi 能部署任何實現了wsgi的框架。實際上，不需要任何框架也可以用mod_wsgi 部署python程序。使用mod_wsgi的daemon模式，python程序會常駐內存，不會有很大的初始化和銷毀進程方面的開銷，所以性能是好於mod_python的。綜合來說，使用Apache部署python web程序，推薦使用mod_wsgi的daemon模式。
Fastcgi
先說觀點：不建議用fastcgi的方式部署Python web。
前幾年由於lighttpd風頭正勁和豆瓣的成功案例，fastcgi是一種很流行的部署方式。fastcgi與具體語言無關，也與web伺服器無關。是一種通用的部署方式。fastcgi是對於cgi的增強，CGI程序運行在獨立的進程中，並對每個Web請求建立一個進程。面對大量請求，進程的大量建立和消亡使操作系統性能大大下降。
與為每個請求創建一個新的進程不同，FastCGI使用持續的進程來處理一連串的請求。這些進程由FastCGI伺服器管理，而不是web伺服器。 當進來一個請求時，web伺服器把環境變數和這個頁面請求通過一個socket比如FastCGI進程與web伺服器都位於本地）或者一個TCP connection（FastCGI進程在遠端的server farm）傳遞給FastCGI進程。
主流的web伺服器，Apache,lighttpd,nginx 都支持fastcgi，在幾年前，lighttpd的mod_fcgi模塊性能強勁，lighttpd+fastcgi十分流行。無論是python,ruby還是php，都有大量的站點使用這種方式部署。由於nginx的崛起，現在很少有人使用lighttpd了。
fastcgi 並不是專門為python設計，並不是所有的python框架天然的支持fastcgi，通常需要flup這樣的容器來配適。flup由python編寫，和專門的c實現的wsgi容器比起來性能顯得相當不堪。fastcgi的穩定性對於新興的wsgi容器來說也有差距。無論從哪個方面來看，部署python web程序，fastcgi 都已經是過去式。
uwsgi
前幾年nginx還未內置uwsgi模塊的時候，部署uwsgi還是一件挺麻煩的事情。隨著能夠在nginx中直接使用uwsgi模塊，uwsgi已經是最可靠，最方便的高性能python web程序的部署方式了。
在1U的四核XEON伺服器上，一個簡單的wsgi handler甚至能用AB壓到8000以上的qps,這已經是完爆tornado,接近gevent的性能了。 同時，uwsgi的穩定性極好。之前我們有個每天500w-1000w動態請求的站點使用uwsgi部署非常穩定，在一個渣HP 1U 伺服器上，基本不用管它。
上面提到的部署方式都是相對於web網站的方式，在移動互聯網的時代，我們需要的是高性能的API服務，上面這些都是過時的東西。
tornado
tornado 號稱高性能，如果拿他寫網站，其實一般般，只不過跟uwsgi加一些簡單框架差不多而已。它真正的作用，是用來寫API伺服器和長連接的伺服器。
由於tornado能夠直接處理http請求，很多人直接拿他來裸奔直接提供服務。這種方式是不可取的，單線程的tornado只能利用cpu的一個核心，並且一旦阻塞直接就廢了。通常情況下，由supervisor啟動多個tornado進程，通過nginx進行反向代理負載均衡。nginx 1.14 以後的版本反向代理支持長連接，配合tornado的comet效果很好。
tornado還有一些比較奇葩的用法，比如用來做wsgi容器之類的。
gevent
gevent是一個神器，能做的事情很多。在web方面，處理http請求，用起來其實跟tornado差不多，但是要簡陋很多，cookie之類的都沒有。用gevent寫的一些API服務，部署方式還是類似tornado，用supervisor管理多個守護進程，通過nginx做負載均衡。 同樣的它的奇葩用法也和tornado一樣，可以當wsgi容器用。
7. Web 部署任務失敗
直接輸入localhost:8080/sms這個有反應嗎，如果有的話那說明項目部署成功，如果沒反應說明項目部署失敗，你需要查看日誌看看項目到底部署成功沒有。
查看log下面的catalina.log這個文件，看看有沒有error
8. eclipse中tomcat如何識別是否為web工程的，並根據什麼判斷是否能部署到tomcat伺服器上的
java吧11級大神!!!
膜拜膜拜..
不了解 但是知道可以搜
maven部署到tomcat 用eclipse自動部署要配置pom.xml,setting.xml還要給tomcat配置用戶 eclipse直接新建要插件吧
以前看過一點 一直沒學maven
大神可以去看看csdn和新浪的博客 網路一下maven部署tomcat
最後javaProject 和 Dynamic Web Project
新建動態web項目的時候 在eclipse的伺服器項目中的server.xml中 已經添加了項目信息 然後eclipse再將改項目載入到eclipse下的tomcat工作空間下的
而普通項目則不會